.NET的MVVM框架描述

　　Model-View-ViewModel是一種架構模式，主要在WPF、Silverlight和WP7開發里使用，它的目標是從視圖層移除幾乎所有代碼隱藏(code-behind)。交互設計師可以專注于使用XAML表達用戶體驗需求，然后創建和視圖模型的綁定，而視圖模型則是由應用程序開發者開發和維護的。

　　MVVM是更加通用的Presentation模式的一個具體實現。MVVM視圖模型包含概念模型而不是數據模型，所有業務邏輯和其它操作都是在模型和視圖模型里完成的。有很多框架可以做到這點，其中一些是：

　　開源的

　　PRISM：由微軟提供，和MEF/Unity一起用于依賴注入，支持組合命令，可以擴展。MSDN上有詳細的教程和演練。

　　MVVM Light Toolkit：有visual Studio和Expression Blend的項目和項的模板。更多信息請看這里，另外可以參考VS和Expression Blend的使用教程。

　　Caliburn Micro：支持視圖模型先行(ViewModel-First)和視圖先行(View-First)兩種開發方式，通過co-routine支持異步編程。

　　Simple MVVM Toolkit：提供VS項目和項的模板，依賴注入，支持深拷貝以及模型和視圖模型之間的屬性關聯。

　　Catel：包含項目和項的模板，用戶控件和企業類庫。支持動態視圖模型注入，視圖模型的延遲加載和驗證。還支持WP7專用的視圖模型服務。

　　閉源的

　　Intersoft ClientUI：付費的，只支持WPF和Silverlight，但是，除了MVVM框架，它還提供其它一些特性。

　　Vidyano：免費但不開源。帶有實體映射/虛擬持久化對象(數據容器)，業務規則以及內置基于ACL的安全特性。

　　若想了解MVVM，可以參考以下資料：

　　Laurent Bugnion的《Understanding MVVM Pattern》和《Deep Dive MVVM》

　　微軟Silverlight組的《Understanding the MVVM Pattern in Silverlight Applications》

　　Erik Lebel在InfoQ上的視頻演講《Presentation Pattern》

　　使用MVVM的最大好處之一是分離關注點，以便用戶體驗設計師和應用程序開發者可以并行工作。另一方面，相關的擔憂包括它對于UI操作比較簡單的情況有點殺雞用牛刀的感覺，數據綁定有點難以調試，以及大量使用數據綁定可能帶來性能問題等等。

　　Jonathan Allen在評論里提到幾點錯誤使用MVVM的征兆：

　　1. 你的模型和視圖模型名字相同。

　　視圖模型不應該是對模型的包裝。視圖模型的職責是外部服務的請求中介，比如加載和保存數據。而數據本身，以及驗證和大多數業務邏輯應該放在模型里。

　　我經常強調這點。每當你創建一個視圖模型包裝一個模型，你就在你的API里引入一個巨大漏洞。具體地，任何直接引用這個模型的東西都可能以視圖模型無法察覺的方式改變某個屬性，因此UI也不會有相應的改變。同樣地，模型里計算字段的任何更改也不會回傳給視圖模型。

　　2. 你的視圖和視圖模型名字相同。

　　理想的情況下，視圖模型是不知道使用它們的視圖的，尤其是WPF應用程序有多個窗口共享相同的視圖模型。

　　對于比較小型的應用程序來說，整個應用程序可能只需一個視圖模型。對于比較大型的應用程序來說，主要功能可能需要一個視圖模型，每個次要方面也需要一個，比如配置管理。

　　3. 你沒有代碼隱藏。

　　代碼隱藏既非一個好的東西，亦非一個壞的東西。它只是一個用來放置和視圖或控件相關的邏輯的地方。因此，當我看到一個視圖沒有任何代碼隱藏，我就會馬上檢查是否存在以下問題：

　　視圖模型是否通過名字接觸了特定的控件?

　　視圖模型是否通過命令參數訪問控件?

　　是否使用了EventToCommand或其它可以導致泄露的行為而不是簡單的事件處理程序?

　　MVVM Light的EventToCommand很有問題，因為它會使得控件從屏幕移除之后無法被垃圾回收。

　　4. 視圖模型監聽屬性更改通知

　　如果一個模型的的生命周期比監聽它的事件的視圖模型長，那么可能導致內存泄露。不同于視圖有個Unloaded事件，視圖模型對于生命周期管理沒有很好的方案。因此如果它們關聯到存活期比它們更長的視圖模型的事件，視圖模型將會出現泄露。

原文轉自：http://www.anti-gravitydesign.com