ASP.NET MVC中使用View Model分離領域模型
MVC架構模式是近年來編程世界里最長被提及的模式之一，Model View Controller(模型-視圖-控制器，MVC)模式將你的軟件組織并分解成三個截然不同的角色：
◆Model封裝了你的應用數據、應用流程和業務邏輯。
◆View從Model獲取數據并格式化數據以進行顯示。
◆Controller控制程序流程，接收輸入，并把它們傳遞給Model和View。
與其它設計模式不同，MVC模式并沒有直接反映一個你能夠編寫或配置的類結構。相反，MVC更像一個概念上的指導原則或范型。概念上的MVC模式被描述為三個對象——Model、View和Controller——之間的關系。由于View和Controller都可以從Model請求數據，所以Controller和View都依賴Model。任何輸入都通過Controller進入你的系統，然后Controller選擇一個View來發出結果。
Model包含了你的應用邏輯和數據，在你的應用程序中，它很可能是主要的值驅動器。Model沒有任何與表現層相關的特性，而且也和HTTP請求處理職責中完全無關。Domain Model是一個對象層，是對現實世界邏輯、數據和你應用程序所處理的問題的抽象。Domain Model可分為兩大類：SimpleDomainModel和RichDomainModel。
SimpleDomainModel往往是業務對象和數據庫表之間一對一的通信。你已經見過的幾種模式——Active Record、Table Data Gateway，以及DataMapper，所有這些與數據庫相關的設計模式——可以幫助你把與數據庫相關的邏輯組織成一個Domain Model。
RichDomain Model包含復雜的，使用繼承機制緊密聯系在一起的對象網絡，在本書和GoF一書中介紹的眾多模式起著杠桿作用。Rich Domain Models往往是柔性的，精心測試過的，不斷重構的，而且與它們所表達的領域所需的業務邏輯緊密耦合。
采用哪種Domain Model類型取決于你的應用環境。如果你正在建立的是一個非常簡單的表單處理web應用，沒必要建立RichDomain Model。然而，如果你正在編寫一個價值數百萬的企業內聯網架構的核心庫，那么努力開發一個RichDomain Model就是值得的，它可以為你提供一個準確表達業務過程的平臺，并可以讓你快速傳輸數據。
MartinFowler在PoEAA中同時簡要介紹了兩種Domain Model。而EricEvans的Domain Driven Design一書，則完全專注于Rich Domain Model的實踐應用和開發過程。View用于處理所有表現層方面的問題。View從Model獲取數據，并可以把它格式化成用于web頁的HTML，用于web服務的XML，或用于email的文本。
許多的MVC模式的實現也都使用一個View Model或Application Model的概念，Controller是溝通的媒介，架起領域模型和用戶界面之間的橋梁，屬于表現層。為了View的簡單性，Controller負責處理或者將領域模型轉換成一個View Model，這通常叫做數據傳輸對象（DTO）。12個ASP.NET MVC最佳實踐針對Model的最佳實踐有這么一段：
7–DomainModel!=View Model
Domain Model代表著相應的域，但View Model卻是為View的需要而創建。這兩者之間或許(一般情況下都)是不同的，此外Domain Model是數據加上行為的組合體，是由復雜的變量類型組成的并且具有層次。而ViewModel只是由一些String等簡單變量類型組成。如果想移除冗余并且容易導致出錯的ORM代碼,可以使用AutoMapper.如果想要了解更多，我推薦閱讀：ASP.NET MVCView ModelPatterns，那么領域模型（Domain Model）和視圖模型（View Model）有什么不同呢？
在ASP.NETMVC的應用程序中經常可以可以看到View Model，經常我們都認為領域模型和視圖模型是同一個東西。這特別是把領域模型包含在數據傳輸對象DTO里的時候，例如使用EntityFramework之類的ORM工具生成的實體。在這種情況下，領域模型和視圖模型包含的實體非常相似，都是一些簡單的CRUD操作。
這些實體有許多屬性，有相同或類似的名稱，你可以很容易地映射領域實體對應視圖模型中的一個屬性。不過，這些相似的屬性也可能略有不同，例如類型或者格式。例如，用戶填寫的用戶界面的一個屬性，他在視圖模型里可能是一個“Nullable”的。
另一方面，領域實體可能需要一個經過驗證的合法的值，所以需要一個在用戶界面的領域模型之間的轉換。另一個例子是，用戶界面可能會顯示一個滑塊，用于用戶選擇多少天以后提交他的訂單。在這種情況下，視圖模型可能使用一個整數屬性來表示，領域模型通常是一個日期值。
視圖模型通常只包含領域模型的一個子集，而且只包含界面上所需要的屬性。此外，視圖模型可能是一個領域模型樹的扁平版本，例如，一個Customer實體有一個Address，而這又是一個整體，它包含街道地址，郵政編碼，國家等。一個Customer視圖模型用于顯示數據，將地址數據拉平填充到視圖模型類里。
此外如果一個View需要同時處理幾個領域模型，View Model就是這幾個DomainModel的總和。領域模型和視圖模型之間有很多相似的地方，我們經常干脆就把DomainModel當作View Model來使用了。上面討論了領域模型和視圖模型的相似性，我們來看看都有幾種方式把領域模型轉換為視圖模型，通常有3種方法：
1.把領域模型當作視圖模型來用，也就是領域模型就是視圖模型，大部分都是這么用的。
2.視圖模型里面包含一個領域模型，定義一個視圖模型，里面包含了一個領域模型，通過屬性方式進行訪問。
3.將領域模型映射到視圖模型，領域模型并沒有直接映射到視圖模型，需要處理這種映射關系。
我們不建議直接把領域模型實體暴露給視圖，因為有許多細微之處，可能導致您混合業務和表示層的邏輯，無論是領域實體的屬性顯示還是業務的驗證規則，這都是應用程序處理的不同方面。
直接將你的領域模型作為Conroller上的處理參數面臨著安全風險，因為Controller或者Modelbinder必須確保屬性驗證和用戶不能修改她自己不能修改的屬性（例如，用戶手動更新了一個隱藏的輸入值，或增加一個額外的屬性值，而這個并不是界面上的元素，但卻正好領域模型實體的屬性，這種風險叫做“over-posting”），即使對當前版本的領域模型做了正確的驗證，領域模型將來可能做了變更修改，并沒有出現編譯錯誤或者警告，可能導致新的風險。
我們應當避免使用前兩種方法將領域模型轉換成視圖模型，推薦使用第三種方法，定義單獨的視圖模型類。做這種領域模型到視圖模型的轉換工作是一種重復性的工作，已經有幾個工具可以幫助你來完成這項工作。最常用的一個工具就是.NET社區的開源項目AutoMapper。
文章轉自自由、創新、研究、探索的博客，
原文地址：http://www.cnblogs.com/shanyou/archive/2010/04/03/1703501.html
【編輯推薦】
