架構設計的歷史·MVC·MVP·MVVM

喜歡本文的請隨意轉載，但請留下原文地址，謝謝：

知識來自於經驗的積累，而歷史是最深遠的經驗。——偶自己O(∩_∩)O~

一、MVC

經典版：

1979年，Trygve Reenskaug在一篇論文中提出MVC模型。

當時，具有強大互動能力的作業系統並不存在，而且並沒有當下的控制元件概念，系統接收的都是直接來自滑鼠和鍵盤的事件。

所以當時的概念中：

View，是僅僅用於展示，沒有互動能力的木偶檢視。

Controller，才是與使用者互動的直接物件，分發滑鼠和鍵盤的事件。

Model，更大意義上是一個動詞，是對整個業務場景的抽象建模。

沒錯，你沒有看錯，在原版的MVC中，View是通過觀察者模式，直接在Model中註冊，然後經由Model更新介面的，而在下方，你將會看見更為熟悉的示意圖。

變體1：

控制元件系統或說是元件化思想的發展，促使View與Controller被封裝成一個個具有互動能力的控制元件。而且強大的作業系統也成長起來，大量的鍵鼠事件被它們管理起來。

於是View，開始成為與使用者互動的直接物件，

而對於Controller來說，來自鍵盤和滑鼠的事件則被抽象為View所發出的事件，

於是，當下常見的MVC示意圖誕生了：

變體2：

某些場景下，人們認為View和Model應該更進一步解耦，於是將對資料的訂閱下放到Controller層，如下圖：

此時一定會有人大呼，這不是MVP嗎？好吧，下面就會說道MVP，但是在此之前，有必要看一下剩下的變體。

更多變體：

主要是業務邏輯的部分，可能分出一部分在Controller或View層，當然，嚴格來說是不符合規範的，但是當實際編碼時，總是會有各種各樣的原因造成此類情況，這個。。你們懂的~~

二、MVP

雖然上面示意圖中，Controller畫成一大塊，但實際情況是，Controller是由很多小Controller組成的，它們或多或少的與View對應，就像View其實是由許多介面組成的一樣。

懶，是人的天性，不僅推動了時下熱門的懶人經濟，也推動著科學技術的發展。Controller就是懶人們的下一個目標，而在歷史的那一刻站出來的懶人，他叫Mike Potel。

1996年，一篇論文中，他在MVC變體1（那個時候，控制元件系統已經成熟）的基礎上，提出了MVP模型，與 MVC變體1 最大的區別在於：

Presenter是一個總控系統，取代了大大小小的Controller們。

其原話：we refer to this kind of controller as a presenter.

看，Presenter是一個特殊的Controller。它與經典版MVC中的C差異更大：

1、它是總控系統。

2、它接收來自控制元件系統的訊息。

如圖：

當然，MVP也有相應的解耦版變體：

三、MVVM

最後，來說說真正比較大的改變：

2005年，微軟的架構師John Gossman推出了MVVM模式。

其核心部分是DataBinding機制。顧名思義，其功能就是將Model的資料繫結到View層，甚至是將View層控制元件的變換繫結到Model的雙向繫結。

但是此前說了，Model是對現實場景的建模，但並非對UI介面的建模，所以Model往往並不能直接與View進行繫結，所以需要新增一箇中介，對View層進行建模，即ViewModel：

MVVM真正的創舉在於對檢視建模的思想，特別是當下的移動時代，對於開發有著豐富介面互動體驗的開發者來說，ViewModel似乎更契合業務場景。同時，強大的DataBinding機制也大大減少了工作量。

不過正如大家所想，ViewModel也是與View一一對應的，所以會有很多很多個ViewModel，是不是有一種似曾相識的感覺？

歷史上的事情總是相似的。

太陽之下無新鮮事——所羅門

沒錯，推動技術革新的懶人們，不，是天才們很快又會站出來：

「寫那麼多ViewModel實在是太麻煩啦！」

當然，那是另外的故事了。

欲知詳情，歡迎關注我，並欣賞另一篇文章《Android架構設計的變遷》

如有不當之處，還請各位斧正，謝謝。