前言
前一階段對MVC模式及其衍生模式做了一番比較深入的研究和實踐，這篇文章也算是一個階段性的回顧和總結。
經典MVC模式
經典MVC模式中，M是指業務模型，V是指用戶界面，C則是控制器，使用MVC的目的是將M和V的實現代碼分離，從而使同一個程序可以使用不同的表現形式。其中，View的定義比較清晰，就是用戶界面。但對於Model和Controller的定義則較為模糊，以致在項目實踐中對它們的職責產生了很多不同的理解。其中比較主流的有下面兩種。
1、閉環黨
比較傳統，問題是Model和Controller職責不清，在實操時容易走形
2、 開放派
MVP的前身，問題是Controller職責太重，優點是View和Model沒有了直接的關聯
對MVP的一點淺見
如果我們希望View和Model脫離關聯的話，那么很容易就會使得所有的職能都落到Controller頭上，就如同上圖所示。這樣，Controller也就變成了Presenter，MVC也正式演化為MVP。所有的數據都由Presenter來驅動，所有的業務邏輯也由Presenter來實現。
MVP模式常見於Android，是谷歌官方推薦的App設計模式。從我找到的這張圖上，可以非常明顯地看出三者之間的關系。
Model只是一個數據通道，退化成了Repository。如果將Model擴而大之，那么就會變成下面這張圖描述的場景：
Model搖身一變，成了一個數據交換中心。
MVP模式的優點是實現了View和Model的解耦，缺點是Presenter職責太重。
對MVVM的一些理解
MVVM模式現在非常流行，下面這張圖描述了MVVM模式各部分的關系和職能：
MVVM模式同樣實現了View和Model的解耦。不過和MVP模式不同的是，MVVM是從數據驅動的角度出發來解決這個問題的。ViewModel和View實現雙向數據綁定，ViewModel的數據變化自動地反應到View上。這樣，ViewModel就代表了View，成了一個Agent。ViewModel也承擔一點業務邏輯，但非常有限（也有把大量業務邏輯放在ViewModel里面的做法，這個就和MVP沒什么本質區別了）。所以，業務邏輯的職能就只能由Model來扛了。事實上，MVVM模式本質上是MVC模式去掉了Controller或者說是Model合並了Controller。
MVVM模式的優點是雙向數據綁定帶來的便利，Model完全不需要關心View。以數據為核心的視角非常新穎，並且在處理業務邏輯上也更加直觀。缺點其實和MVP一樣，只不過它是Model臃腫而已。
我們為什么需要MVC？
MVC、MVP、MVVM（這里把它們統稱為MVC），這種模式的真正好處是什么？說實話，這個問題好思考了很久，腦海里閃過的答案總覺得似乎還差那么一點。最終，梳理出以下幾點，和大家探討：
專業分工的需要
程序員和設計師的技能是完全不同的，用戶界面就應該由設計師來完成而非程序員。所以，我們需要一個不包含任何邏輯代碼的View，以便由設計師來完成用戶界面的創建工作。程序員則可以專心去做和邏輯、數據相關的工作。在這個層面上，不需要考慮讓人糟心的Model/Controller還是Model/Presenter或者Model/ViewModel如何划分職責的問題。View的分離顯然非常成功！
應對變化的需要
既然用戶界面的問題已經得到了完美解決，那么，就該輪到業務邏輯和數據處理的問題了。需求總是在不斷變化，程序猿對於產品狗的敵意就來自於不斷地更改需求。於是，少改、好改就成了程序員的永恆目標。行之有效的套路其實也就是分層解耦而已。無論是Model/Controller還是Model/Presenter或者Model/ViewModel，不過是分層的角度和方法不同而已。
流程工藝的需要
在軟件工程領域，規范提得很多，流程提得很少，工藝幾乎沒有人提過。但在傳統的制造業和工程施工領域，最核心的就是流程和工藝。流程和工藝，是工業化生產的組織和產品品質的基礎。
在軟件工程上，代碼風格規范就是一種工藝，瀑布式開發或者敏捷開發都是流程。如何划分Model和Controller的職責，是軟件的一個設計過程，也屬於工藝的范疇。三者之間如何依賴，其本質是一個流程問題。被依賴的一定是先於依賴者被生產出來。明確了職責划分和依賴關系，才能科學地編制開發計划，保證產出的代碼的品質和效率。
有『套路』可循，我們做起事情來總是會簡單快捷許多。
傳統MVC模式存在的問題
我們知道，經典MVC模式早先的主要問題是Model和Controller的職責不明，但現在，主要問題是無法進行單元測試。既然已經知道問題在哪里，那么，我們來想辦法解決問題就好了，但這之前，還需要解決幾個別的問題。
業務邏輯、界面邏輯和數據邏輯傻傻分不清
從廣義上講，無論是點擊按鈕打開一個對話框，還是撥動一個開關切換界面樣式，或者驗證輸入數據的合法性，都是業務邏輯，並沒有什么必要分得那么細。從某種意義上，把業務邏輯分為內在的、直接的反應，和需要用戶進一步操作的，狀態不確定的過程，可能更加有用。前者例如分頁顯示的列表用戶點擊了下一頁按鈕，從而產生了刷新數據的指令；后者例如用戶點擊了編輯按鈕，是否會修改數據，修改成什么數據在這個時候都是未知的。
三者之間如何依賴
這是一個大問題！經典的VMC模式中，View是依賴於Model的。但我個人的理解是View是需求的最直接的體現，所以View應該是先驗的存在，應該是Model依賴View而不是相反。在實際的項目中，在確定原型后，設計師和負責接口的程序員會同時開始工作。同時，測試工程師也會開始編寫測試用例和單元測試代碼。他們的工作依據都是產品給出的原型。
等一個View編寫完成后，依賴於這個View的Model就可以開工了，每一個View都會對於着一個Model和若干的接口。最后，就輪到依賴於若干Model的Controller登場了。這樣做的好處是整個開發過程是由底向上、由表入里的，整體過程非常自然，而且結構簡潔明了。
如何划分Model和Controller的職責
這是一個更大的問題，足以引起開發者的爭吵不休，就如同什么語言最好一樣。
拋開這些分歧，我們就會看到，無論是什么模式，它所需要解決的無非是業務邏輯和數據問題！所以，我認為問題的本質不是誰負責什么，而是如何分離業務邏輯和數據。
特定的用戶界面需要特點的數據，有着特定的業務邏輯。這個前提之下，解耦是沒有意義的。我們要求的職責分明，無非是為了更容易應對變化。那么，都有哪些變化呢？
- 界面樣式變了，但業務邏輯和數據都沒有變
- 界面樣式和業務邏輯變了，但數據沒有變
- 界面和數據變了，但業務邏輯沒有變
- 界面和數據沒有變，但業務邏輯變了
- 全都變了
界面的改變可以分為兩種，一是樣式改變，這種變化無關其他；另一種是元素變化，必然對應着數據的變化，需要修改接口。另外，就是業務邏輯的改變，而業務邏輯和數據並不存在必然關系。在MVC模式下，View的數據來源於Model，那么，Model的職責就是負責View和接口之間的數據交互，起一個數據通道或者說是數據引擎的作用。當數據發生變化的時候，只需要修改Model即可。
既然Model承擔了數據引擎的職責，那業務邏輯就應該由Controller來承擔。同時，因為不同的View之間也會存在交互，那么，也需要一共同的個中間人來進行轉接和調度，由於Model和View是一對一的綁定關系，並不適合承擔這個責任。所以，Controller負責業務邏輯是天然的。不過，那些和數據直接相關的事件，例如改變了一個選項后引起可用數據的變化、切換分頁加載新數據之類的和具體業務沒有關系的簡單反應型的業務邏輯，我覺得交給Model去實現更簡單和直接，並不一定要經過Controller去驅動Model。
在這種模式下，Model負責數據，Controller負責業務邏輯，整體是非常協調的。反過來看MVP和MVVM，因為回避職責的划分的問題導致了Presenter或Model的臃腫。
View和Model要不要雙向數據綁定
非常有必要！傳統的MVC是沒有雙向綁定的，這樣，View上面數據的變化就必須通過Controller去修改Model。而建立雙向綁定后，Controller就無需承擔這個職責了，從整體上看，職責更加分明，邏輯也會更加簡單。
改進的MVC模式
解決了以上四個問題，我們可以得到這樣的一個新的MVC模式：
這種改進模式，相對傳統的MVC模式，解決了職責不清的問題。相對於MVP和MVVM而言，沒有因回避職責划分問題導致的龐大而混亂的Presenter/Model。在僅僅是View樣式不同的場景下，Model是可以復用的。而使用哪個View，可以通過重載Model的構造函數來決定。事實上，即使View的元素不同造成數據不同，Model也可以利用泛型等技術手段來達到重用代碼的目的。
因為View並不依賴任何人，所以，我們可以很方便地把View替換成單元測試代碼（View本身是可根據場景需要相互替換的），只要騙過Model就OK。這個測試類一旦被Model構造出來，就會自動驗證數據、模擬用戶更新數據和發出指令。
在項目中展開的話，結構如下圖：
后記
這不是結束，而是一個開始……