表現層持續解耦帶來(lái)的模式轉變 MVC MVP MVVM (微軟WPF帶來(lái)的團隊變化和軟件技術(shù)變化)
2012年03月08日 星期四 下午 10:34
Model-View-ViewModel是一種架構模式，主要在WPF、Silverlight和WP7開(kāi)發(fā)里使用，它的目標是從視圖層移除幾乎所有代碼隱藏（code-behind）。交互設計師可以專(zhuān)注于使用XAML表達用戶(hù)體驗需求，然后創(chuàng )建和視圖模型的綁定，而視圖模型則是由應用程序開(kāi)發(fā)者開(kāi)發(fā)和維護的。
MVVM是更加通用的Presentation模式的一個(gè)具體實(shí)現。MVVM視圖模型包含概念模型而不是數據模型，所有業(yè)務(wù)邏輯和其它操作都是在模型和視圖模型里完成的。
MVVM 把應用程序的狀態(tài)和行為進(jìn)行封裝，隔離了用戶(hù)界面和用戶(hù)體驗部分，從而使得設計者與開(kāi)發(fā)者可獨立工作，并易于協(xié)作。開(kāi)發(fā)者可迅速的投入代碼開(kāi)發(fā)中，只關(guān)注應用邏輯即可。如果實(shí)現一些相對較小，后期變化不大的應用程序，可能并不關(guān)注設計模式，使用設計模式反而帶來(lái)復雜度。但ViewModel卻具備良好的伸縮性，在小型應用中也可帶來(lái)不菲的好處。它還易于在最終的應用程序中利用開(kāi)始構建的原型系統，使得異步編程變得簡(jiǎn)單等等。
在MVP模式中，為了讓UI層能夠從邏輯層上分離下來(lái)，設計師們在UI層與邏輯層之間加了一層interface。無(wú)論是UI開(kāi)發(fā)人員還是數據開(kāi)發(fā)人員，都要尊重這個(gè)契約、按照它進(jìn)行設計和開(kāi)發(fā)。這樣，理想狀態(tài)下無(wú)論是Web UI還是Window UI就都可以使用同一套數據邏輯了。
與用戶(hù)界面相關(guān)的最大的問(wèn)題就是大量的凌亂的代碼，
a) 用戶(hù)界面包含負責的邏輯用于維護界面相關(guān)對象;
b) 包含了應用程序狀態(tài)的維護;
表現模式 (Presentation patterns) 就是圍繞如何移除用戶(hù)界面的復雜性，讓界面更加簡(jiǎn)潔和可管理而產(chǎn)生的，下圖就是常見(jiàn)表現模式的種類(lèi)與分類(lèi)：
（1） MVC：模型－視圖－控制器(Model View Controller)，它強制性的使應用程序的輸入、處理和輸出分開(kāi)。
（2） MVP：模型－視圖－表現類(lèi)（Model-View-Presenter）
（3） MVVM：模型－視圖－視圖模型（Model-View-ViewModel）
（a） 發(fā)展過(guò)程：MVC->MVP->MVVM
（b） MVC->MVP
（c） MVC、MVP->MVVM
用戶(hù)界面的3大問(wèn)題：狀態(tài) (State) ， 邏輯 (Logic) ，同步 (Synchronization)
狀態(tài) (State) ： 狀態(tài)是用戶(hù)界面最關(guān)心的問(wèn)題之一。狀態(tài)是用戶(hù)界面數據的當前快照，在 Web 應用中，可能是 Session 級別的一個(gè)變量，在 Windows 應用中， 則可能只是界面級別的數據。 用戶(hù)界面包含的狀態(tài)越多， 則用戶(hù)界面越復雜。 邏輯 (Logic) ： 用戶(hù)界面往往包含界面邏輯，例如維護文本框、組合框或者其它任何界面元素，用戶(hù)界面中這種邏輯越多，則用戶(hù)界面越復雜。 同步 (Synchronization) ： 用戶(hù)界面通常需要和業(yè)務(wù)組件協(xié)作，因此用戶(hù)界面需要在界面元素與業(yè)務(wù)對象之間同步數據，如果用戶(hù)界面包含的同步任務(wù)越多，則用戶(hù)界面越復雜。 .
MVC
MVP
MVVM
V
C
V
P
V
VM
狀態(tài)
√
√
√
邏輯
√
√
√
同步
√
√
√
表現設計模式 (Presentation Design Pattern)
表現設計模式有助于解決上面列出的問(wèn)題， 它的的基本邏輯就是創(chuàng )建一個(gè)額外的表現類(lèi) (Presenter) ，用來(lái)消化用戶(hù)界面中復雜的邏輯，數據和同步的問(wèn)題，從而使得用戶(hù)界面變得簡(jiǎn)單明了。根據這個(gè)類(lèi)承擔責任的多少，決定了表現設計模式的類(lèi)型，可能是 SC , PV , PM 等，也就是說(shuō)，這個(gè)類(lèi)的成熟度決定了它將是那種設計模式。
表現模型 (PM)
表現類(lèi)包含邏輯 表現類(lèi)包含狀態(tài) 表現類(lèi)代表抽象的用戶(hù)界面 表現類(lèi)不關(guān)注用戶(hù)界面 視圖關(guān)注表現類(lèi) 視圖與業(yè)務(wù)模型完全隔離
MVVM
繼承自表現模型 使用 WPF 以及 Silverlight 的綁定機制
MVC
沒(méi)有表現類(lèi)，有控制器 (Controller) 請求首先到達控制器 控制器負責綁定視圖與業(yè)務(wù)模型 邏輯存在于控制器中
什么是 MVVM
MVVM的提出源于WPF，主要是用于分離應用界面層和業(yè)務(wù)邏輯層，以前的ASP.Net三層架構是Web架構，MVVM是Windows應用程序架構。WPF用Xaml繪制界面，繪制完的界面是個(gè)獨立的文件，文件里包含界面所有的樣式和行為（行為是對行動(dòng)的一種封裝）。
為什么使用 MVVM
MVVM實(shí)際上是三層架構，M層（Model實(shí)體層）、V層（View表示層，它有DataContext屬性，這個(gè)屬性可以使用DataTemplate模板綁定VM層的數據用來(lái)顯示）、VM層（ViewModel層，對Model層進(jìn)行CRUD進(jìn)行操作，同時(shí)對V層提供數據綁定）。
命令對象
漫談消息
triggers，actions，behaviors
傳統的WinForm和ASP.NET應用程序是基于事件驅動(dòng)開(kāi)發(fā)的，以ASP.NET為例，在實(shí)際開(kāi)發(fā)中，*.aspx頁(yè)面用于渲染HTML，*.aspx.cs頁(yè)面用于實(shí)現服務(wù)端邏輯，在開(kāi)發(fā)初期，這種方式顯得方便快捷，但是這種高耦合性導致了后期維護的復雜性，一旦aspx變化，aspx.cs的代碼同時(shí)需要改變，比如將aspx中的GridView控件以FormView控件進(jìn)行替換，對應的aspx.cs文件中不得不進(jìn)行大量修改。而MVVM模式在WPF/SL應用程序中得以廣泛應用的原因是，WPF/Siverlight應用程序是基于數據驅動(dòng)的開(kāi)發(fā)的，網(wǎng)上曾有研究者在WinForm下實(shí)現MVVM模式與WPF進(jìn)行對比，得出結論：WinForm項目中大規模運用MVVM模式開(kāi)發(fā)效率很低。
與MVC,MVP所不同的是,MVVM的引入不僅僅是技術(shù)上解除耦合應對變化的原因，另外一個(gè)很大原因是:軟件團隊開(kāi)發(fā)方式的改變.
為什么MVC/MVP模式不行而MVVM可以呢? 很簡(jiǎn)單, 在MVC和MVP模式中, View層都具有很多代碼邏輯, 開(kāi)發(fā)View層的是程序員, 雖然UI/UE團隊會(huì )做很多工作, 但這個(gè)層的"實(shí)現者"仍然是程序員. 在以前的開(kāi)發(fā)中,其工作得很好, 而在WPF開(kāi)發(fā)中程序員對View層的展現顯得力不從心了,美工雖然很擅長(cháng), 但他會(huì )說(shuō)"可惜我不會(huì )程序".于是, 我們需要一種方式將View層的代碼邏輯抽取出來(lái),并View層很純粹以便完全讓美工去打造它.相應地, 需要將View層的相應邏輯抽取到一個(gè)代碼層上,以便讓程序員專(zhuān)注在這里.
我們只所以要在View(Xaml)背后寫(xiě)一些代碼(C#), 無(wú)非是想傳遞一些數據以及傳遞數據時(shí)的數據的處理或在用戶(hù)與界面控件進(jìn)行交互時(shí)執行一些操作, 最簡(jiǎn)單的例子是在MVC中當界面發(fā)生交互時(shí)View去調用Controler中的某個(gè)方法, 以便將該操作的相應"指示"傳遞到"后臺"去. 在以前的技術(shù)中, 這樣的"銜接性"的代碼是必須的.而在WPF中, 則可以通過(guò)另外的技術(shù)來(lái)進(jìn)行層與層之間的"銜接", 這就是"Binding" 、"Command"、"AttachBehavior".通過(guò)Binding,我們可以實(shí)現數據的傳遞; 通過(guò)Command,我們可以實(shí)現操作的調用.Binding和Command是可以寫(xiě)在XAML中的, 這樣看來(lái)XAML后面對于的CS文件可以被完全拋棄或不予理會(huì )了.這樣的XAML文件正是美工所需要的. 而這些對于Binding以及Command的定義描述以及其他相關(guān)信息的代碼應該放在那里呢,當然不是View, 更不是Model, 是"ViewModel". ViewModel是為這個(gè)View所量身定制的, 它包含了Binding是所需的相關(guān)信息,比如Converter以及為View的Binding提供DataContext, 它包含了Command的定義以便View層可以直接使用,另外,它還是一個(gè)變種的Controler, 它得負責業(yè)務(wù)流程的調度.
在WPF/Silverlight中應用MVVM模式，View主要用于界面呈現，ViewModel用于邏輯實(shí)現，Model用于數據的構造，而這三者能夠進(jìn)行通信，最重要的是通過(guò)WPF/Silverlight中強大的數據綁定機制，將View和ViewModel有效的聯(lián)系起來(lái)。
盡管在MVVM模式的名稱(chēng)沒(méi)有體現Command，但是在實(shí)際情形中，Command是實(shí)現MVVM至關(guān)重要的一環(huán)，目前項目主要采用了Prism框架中的DelegateCommand<T>類(lèi)
在Silverlight項目中采用MVVM模式，優(yōu)勢是顯而易見(jiàn)的：
1,對于視圖-邏輯的分離便于后期對原有功能擴展和維護，當UI變化時(shí)，ViewModel中的邏輯不需要進(jìn)行變化
2,可以?xún)H僅通過(guò)Blend實(shí)現簡(jiǎn)單的功能，而不需要寫(xiě)任何代碼。
在實(shí)現過(guò)程中，不要只是為了實(shí)現MVVM而MVVM，而應該根據實(shí)際情況進(jìn)行取舍，事實(shí)上，由于Silverlight只是WPF的一個(gè)子集，其對MVVM模式在某些方面的支持仍有所欠缺：
1，對枚舉類(lèi)型綁定比較困難，如將枚舉類(lèi)型綁定至RadioButton
2，Silverlight4中僅僅對繼承ButtonBase的控件實(shí)現了Command屬性，在實(shí)際的使用中，對于其它的事件可以使用Blend4中中的InvokeCommandAction
3，無(wú)法在View和ViewModel傳遞復雜對象，可以破壞View或者ViewModel作為折衷辦法，如ChildWindow和父容器的對象傳遞
有很多MVVM框架可以做到這點(diǎn)，其中一些是：
開(kāi)源的
PRISM：由微軟提供，和MEF/Unity一起用于依賴(lài)注入，支持組合命令，
可以擴展。
MSDN上有詳細的教程和演練。
MVVM Light Toolkit：有visual Studio和Expression Blend的項目和項的模板。更多信息請看
這里，另外可以參考
VS和
Expression Blend的使用教程。
Caliburn Micro：支持視圖模型先行（ViewModel-First）和視圖先行（View-First）兩種開(kāi)發(fā)方式，通過(guò)co-routine支持異步編程。
Simple MVVM Toolkit：提供VS項目和項的模板，依賴(lài)注入，支持深拷貝以及模型和視圖模型之間的屬性關(guān)聯(lián)。
Catel：包含項目和項的模板，用戶(hù)控件和企業(yè)類(lèi)庫。支持動(dòng)態(tài)視圖模型注入，視圖模型的延遲加載和驗證。還支持WP7專(zhuān)用的視圖模型服務(wù)。
閉源的
Intersoft
ClientUI：付費的，只支持WPF和Silverlight，但是，除了MVVM框架，它還提供
其它一些特性。
Vidyano：免費但不開(kāi)源。帶有實(shí)體映射/虛擬持久化對象（數據容器），業(yè)務(wù)規則以及內置基于A(yíng)CL的安全特性。
若想了解MVVM，可以參考以下資料：
Laurent Bugnion的
《Understanding MVVM Pattern》和
《Deep Dive MVVM》 微軟Silverlight組的
《Understanding the MVVM Pattern in Silverlight Applications》 Erik Lebel在InfoQ上的視頻演講
《Presentation Pattern》使用MVVM的最大好處之一是分離關(guān)注點(diǎn)，以便用戶(hù)體驗設計師和應用程序開(kāi)發(fā)者可以并行工作。另一方面，相關(guān)的擔憂(yōu)包括它對于UI操作比較簡(jiǎn)單的情況有點(diǎn)殺雞用牛刀的感覺(jué)，數據綁定有點(diǎn)難以調試，以及大量使用數據綁定可能帶來(lái)性能問(wèn)題等等。
Jonathan Allen在評論里提到幾點(diǎn)錯誤使用MVVM的征兆：
1. 你的模型和視圖模型名字相同。
視圖模型不應該是對模型的包裝。視圖模型的職責是外部服務(wù)的請求中介，比如加載和保存數據。而數據本身，以及驗證和大多數業(yè)務(wù)邏輯應該放在模型里。
我經(jīng)常強調這點(diǎn)。每當你創(chuàng )建一個(gè)視圖模型包裝一個(gè)模型，你就在你的API里引入一個(gè)巨大漏洞。具體地，任何直接引用這個(gè)模型的東西都可能以視圖模型無(wú)法察覺(jué)的方式改變某個(gè)屬性，因此UI也不會(huì )有相應的改變。同樣地，模型里計算字段的任何更改也不會(huì )回傳給視圖模型。
2. 你的視圖和視圖模型名字相同。
理想的情況下，視圖模型是不知道使用它們的視圖的，尤其是WPF應用程序有多個(gè)窗口共享相同的視圖模型。
對于比較小型的應用程序來(lái)說(shuō)，整個(gè)應用程序可能只需一個(gè)視圖模型。對于比較大型的應用程序來(lái)說(shuō)，主要功能可能需要一個(gè)視圖模型，每個(gè)次要方面也需要一個(gè)，比如配置管理。
3. 你沒(méi)有代碼隱藏。
代碼隱藏既非一個(gè)好的東西，亦非一個(gè)壞的東西。它只是一個(gè)用來(lái)放置和視圖或控件相關(guān)的邏輯的地方。因此，當我看到一個(gè)視圖沒(méi)有任何代碼隱藏，我就會(huì )馬上檢查是否存在以下問(wèn)題：
視圖模型是否通過(guò)名字接觸了特定的控件？ 視圖模型是否通過(guò)命令參數訪(fǎng)問(wèn)控件？ 是否使用了EventToCommand或其它可以導致泄露的行為而不是簡(jiǎn)單的事件處理程序？
MVVM Light的EventToCommand很有問(wèn)題，因為它會(huì )使得控件從屏幕移除之后無(wú)法被垃圾回收。
4. 視圖模型監聽(tīng)屬性更改通知
如果一個(gè)模型的的生命周期比監聽(tīng)它的事件的視圖模型長(cháng)，那么可能導致內存泄露。不同于視圖有個(gè)Unloaded事件，視圖模型對于生命周期管理沒(méi)有很好的方案。因此如果它們關(guān)聯(lián)到存活期比它們更長(cháng)的視圖模型的事件，視圖模型將會(huì )出現泄露。
