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