天天看點

對MVC、MVP、MVVM的了解

最近看了一堆js架構的文檔,有點亂,想分門别類整理一下,但是首先需要搞清楚這些架構裡面經常談論的MV*之類的概念。MVC的概念很早就知道,現在發現還有MVP、MVVM,那麼這些設計模式有什麼差別呢?談一下自己的了解。

剛開始了解這些概念的時候認為這幾種模式雖然都是要将view和model解耦,但是非此即彼,沒有關系,一個應用隻會用一種模式。後來慢慢發現世界絕對不是隻有黑白兩面,中間最大的一塊其實是灰色地帶,同樣,這幾種模式的邊界并非那麼明顯,可能你在自己的應用中都會用到。實際上也根本沒必要去糾結自己到底用的是MVC、MVP還是MVVP,不管黑貓白貓,捉住老鼠就是好貓。

MVC:Model-View-Controller

MVP:Model-View-Presenter

MVVM:Model-View-ViewModel

先說一下三者的共同點,也就是Model和View

Model就是領域模型,資料對象,同時,提供外部對應用程式資料的操作的接口,也可能在資料變化時發出變更通知。Model不依賴于View的實作,隻要外部程式調用Model的接口就能夠實作對資料的增删改查。

View就是UI層,提供對最終使用者的互動操作功能,包括UI展現代碼及一些相關的界面邏輯代碼。

三者的差異在于如何粘合View和Model,實作使用者的互動操作以及變更通知

對MVC、MVP、MVVM的了解

Controller接收View的操作事件,根據事件不同,或者調用Model的接口進行資料操作,或者進行View的跳轉,進而也意味着一個Controller可以對應多個View。Controller對View的實作不太關心,隻會被動地接收,Model的資料變更不通過Controller直接通知View,通常View采用觀察者模式監聽Model的變化。

Presenter,與Controller一樣,接收View的指令,對Model進行操作;與Controller不同的是Presenter會反作用于View,Model的變更通知首先被Presenter獲得,然後Presenter再去更新View。一個Presenter隻對應于一個View。根據Presenter和View對邏輯代碼分擔的程度不同,這種模式又有兩種情況:Passive View和Supervisor Controller。

ViewModel,注意這裡的“Model”指的是View的Model,跟上面那個Model不是一回事。所謂View的Model就是包含View的一些資料屬性和操作的這麼一個東東,這種模式的關鍵技術就是資料綁定(data binding),View的變化會直接影響ViewModel,ViewModel的變化或者内容也會直接展現在View上。這種模式實際上是架構替應用開發者做了一些工作,開發者隻需要較少的代碼就能實作比較複雜的互動。

MVP和MVVM完全隔離了Model和View,但是在有些情況下,資料從Model到ViewModel或者Presenter的拷貝開銷很大,可能也會結合MVC的方式,Model直接通知View進行變更。在實際的應用中很有可能你已經在不知不覺中将幾種模式融合在一起,但是為了代碼的可擴充、可測試性,必須做到子產品的解耦,不相關的代碼不要放在一起。記得幾年前在上一家公司做一個新産品時,一名外包公司的新員工直接在View中做了資料庫持久化操作,而且一個hibernate代碼展開後發現竟然有幾百行的SQL語句,搞得我們驚訝不已,一時成為笑談。

個人了解,在廣義地談論MVC架構時,并非指本文中嚴格定義的MVC,而是指的MV*,也就是視圖和模型的分離,隻要一個架構提供了視圖和模型分離的功能,我們就可以認為它是一個MVC架構。在開發深入之後,可以再體會用到的架構到底是MVC、MVP還是MVVM。

上面如有錯誤,敬請指出,謝謝。

參考資料:

http://joel.inpointform.net/software-development/mvvm-vs-mvp-vs-mvc-the-differences-explained/

http://nirajrules.wordpress.com/2009/07/18/mvc-vs-mvp-vs-mvvm/