Web開發中的設計模式及在DevOps中的演進 （2）

看過上篇文章的小夥伴可能對Django的MTV模式有了大概的了解，算是MVC的一個派生

這兩天查了大量的資料，想回過頭來更好的理解MVC，下面的隱喻很有意思

MVC can be metaphorically related to a TV. You have various channels, with different information on them supplied by your cable provider (the model). The TV screen displays these channels to you (the view). You pressing the buttons on the remote controls affects what you see and how you see it (the controller).

譯：

MVC可以隱喻為電視。 你有各種頻道，有線提供商提供的不同信息（模型M）。 電視屏幕向你顯示這些頻道（視圖V）。 按遙控器上的按鈕會影響您看到的內容以及如何看到它（控制器C）。

我找到一個很好的方式來理解M - V - *（Whatever）

歷史長河中MVC處在一個什麼位置？

剛開始，程序只有命令行；

然後有了『GUI』（View層），於是就有了C/S架構的MVC；

後來互聯網興起，此時的MVC被帶到了B/S架構，瀏覽器成了用戶界面（View層）；

再後來，瀏覽器變得很強大，於是好多業務也放到瀏覽器來實現，程序員把MVC帶到了View層，問題來了：

用戶界面3大問題

狀態 (State) ， 邏輯 (Logic) ，同步(Synchronization)

1. State：狀態是用戶界面數據的當前快照，在 Web 應用中，可能是 Session 級別的一個變數。
2. Logic：用戶界面往往包含界面邏輯，例如維護文本框、組合框或者其它任何界面元素，用戶界面中這種邏輯越多，則用戶界面越複雜。
3. Synchronization：用戶界面通常需要和業務組件協作，因此用戶界面需要在界面元素與業務對象之間同步數據，如果用戶界面包含的同步任務越多，則用戶界面越複雜。

解決問題

表現設計模式（Presentation Design Pattern）出現了，它引入了一個額外的表現類 (Presenter)來解決用戶界面中複雜的邏輯，數據和同步的問題

下面介紹幾種表現設計模式：

筆者註：根據這個類（Presenter）承擔責任的多少，決定了表現設計模式的類型

多圖預警，先上圖例：

監視控制器 (SC - Supervising controller)

原理：

• State is stored in the view. 狀態在視圖中保存
• Presenter owns the complex presentation logic. Simple UI binding logic is taken care by using binding technologies like WPF binding and Silverlight binding. Anything complex is taken care presenter class. 表現類擁有複雜的表現邏輯. 只關注簡單的用戶界面綁定邏輯，比如使用WPF，Silverlight提供的綁定機制。
• Presenter is aware of the view. 表現類關注視圖。
• View is not aware of the presenter. 視圖不關注表現類。
• View connects with model using technical bindings provided by WPF and Silverlight. 視圖通過數據綁定和業務模型進行關聯。

註：關鍵已經標粗體，注意S與L的位置，下一個

被動視圖 (PV)

原理：

• State is stored in the view. 狀態保存在視圖中。
• All logic of UI is stored in presenter. 所有用戶界面的邏輯保存在表現類中。
• View is completely isolated from the model. It also takes the extra task of synchronizing data between model and view. 視圖完全與模型隔離，Presenter多了一些模型與視圖之間的數據同步（下圖中的 update）的工作。
• Presenter is aware of the view. 表現類關注視圖。
• View is not aware of the presenter. 視圖不關注表現類。

註：MVP設計模式符合PV模式，想進一步了解MVP看這裡

表現模型 (PM)

原理：

• State is stored in the presenter. 表現類包含狀態。
• Logic is stored in presenter. 表現類也包含邏輯。
• Presenter represents an（原作者用的『 a 』??） abstract view of the UI. 變現類代表抽像的用戶界面視圖。
• Presenter is not aware of the view. 表現類不關注視圖。
• View is aware of the presenter. 視圖關注表現類。
• View is completely isolated from the model. 視圖和業務模型完全隔離。

註：表現類包含了狀態S和邏輯L，它不關注視圖，但視圖關注它，V和M完全被隔開

MVVM

原理：

• Presenter model is the base. 繼承自表現模型（上文的PM）。
• State is stored in the presenter. （同PM）
• Logic is stored in presenter. （同PM）
• Presenter represents an abstract view of the UI. （同PM）
• Presenter is not aware of the view.（同PM）
• View is aware of the presenter.（同PM）
• View is completely isolated from the model. （同PM）
• Uses WPF and Silverlight bindings. 使用 WPF，Silverlight，以及AngularJS（筆者注）的綁定機制

我加一個：

PM + AngularJS Binding = Angular MVVM

MVC

原理：

• Does not have a presenter , has a controller. 沒有表現類，有個控制器。
• Request first comes to the controller. 請求第一個到控制器。
• Controller binds the model with the view. 控制器綁定模型與視圖。
• Logic is stored in the controller. 邏輯存在於控制器中。

註：想進一步了解MVC可以看這裡

對比：

註：如果感覺表不直觀，有圖 ↓

可視化對比：

我自己的理解與總結，供大家參考：

• MVP - 控制器由表現類（又叫演示者）替換。 演示者坐在與視圖相同的水平。 演示者監聽視圖和模型的事件，並調解視圖和模型之間的交互。它主要用於構建用戶界面，視圖會處理UI事件（滑鼠向下，按鍵等），這些以前是控制器做的，最終，模型變成了嚴格的域模型 - domain model。
• MVP(SC) - 監視控制器模式：控制器由表現類替換，表現類擁有複雜的表現邏輯和簡單的用戶界面綁定邏輯（由WPF/SilverLight等技術等實現）。表現類單方面知道視圖狀態；視圖與模型通過綁定技術實現關聯、同步。
• MVP(PV) - 被動視圖模式：控制器由表現類替換，視圖什麼都不知道（可能是被動的由來），所有界面邏輯都被包含在表現類里。表現類單方面知道視圖狀態；視圖與模型完全獨立，所有同步都經過表現類，所以表現類會承擔一些額外的同步的工作。
• MVP(PM) - 表現模型：表現類包含邏輯和狀態，表現類代表抽象的用戶界面（可能因為它邏輯、狀態都包含了），視圖單向關注表現類，視圖和業務模型完全隔離，老死不相往來。
• MVVM - 繼承自表現模型（PM），
• 控制器由視圖模型替代。 視圖模型位於UI層下面。 視圖模型公開視圖需要的數據和命令對象。 你可以認為這是一個容器對象，視圖去獲取它的數據和操作。 視圖模型從下面的模型中提取其數據。

MVC單獨拿出來

• MVC - 沒有表現類，有控制器，視圖知道控制器，控制器知道模型。邏輯包含在控制器中，控制器負責綁定視圖和業務模型。因為瀏覽器的日益強大，View層裡面可以包含邏輯與狀態。

AngularJS

AngularJS（client-side框架）更接近MVVM模式，即框架內置的雙向綁定技術 + MVP(PM），引入了專門的ViewModel（視圖模型）來實現View和Model的粘合，讓View和Model的進一步分離和解耦。 $scope對象可以被認為是ViewModel，由我們稱為Controller的函數裝飾。

有人稱Angular為MVW（Whatever）框架，因為他們不希望看到程序員花時間爭論MV*中星號到底是什麼，那個Whatever具體說就是任意的JS object.

那麼是否可以這樣理解：

視圖模型（ViewModel）是表現類，包含邏輯與狀態，可以理解為抽象的用戶界面，視圖（HTML）通過框架內置的技術與視圖模型（$scope）雙向綁定。

不知道vue.js（題圖）相比AngularJS有何差異，我是沒發現，了解的同學可以留言討論一下

『 我開發的時候，發現一個簡單架構挺好用的：Django處理M + C（URLconf），View層交給Angular處理，它是MVVM模式 - 所以就出現了M + MVVM + C模式，適合工具集成類的平台開發，因為M層公用，最適合保存業務配置，又因為工具使用的狀態與邏輯不同，所以拆分到MVVM的ViewModel中自治，這樣的話只要開發會使用Angular或者其他MVVM模式的客戶端框架（vue.js）中的一種，就可以實現維護一套配置，多個工具並行開發，前端還可以引入前端模板渲染，還可以自己維護一套URL路由（比如ng-route）來保證邏輯，總之蠻好用的 』

吐槽一下，知乎發布文章需要加標籤，標籤居然沒有『MVP』，有誰知道在哪可以定義標籤？

給看完的同學點個贊，這麼長這麼枯燥都看完了，點個關注、點個贊不麻煩吧 ??

第一部分 已更新

第二部分 已更新（本文 ）

第三部分 已更新

推薦閱讀：