Model-View-Controller（模型-視圖-控制器，MVC）模式將你的軟體組織並分解成三個截然不同的角色： Model 封裝了你的應用數據、應用流程和業務邏輯。 View 從 Model 獲取數據並格式化數據以進行顯示。 Controller 控製程序流程，接收輸入，並把它們傳遞給 Mo ...
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 可分為兩大類：Simple Domain Model 和 Rich Domain Model。
- Simple Domain Model 往往是業務對象和資料庫表之間一對一的通信。你已經見過的幾種模式 —— Active Record、Table Data Gateway，以及 Data Mapper，所有這些與資料庫相關的設計模式 —— 可以幫助你把與資料庫相關的邏輯組織成一個 Domain Model。
- Rich Domain Model 包含複雜的，使用繼承機制緊密聯繫在一起的對象網路，在本書和 GoF 一書中介紹的眾多模式起著杠桿作用。Rich Domain Models 往往是柔性的，精心測試過的，不斷重構的，而且與它們所表達的領域所需的業務邏輯緊密耦合。
採用哪種 Domain Model 類型取決於你的應用環境。如果你正在建立的是一個非常簡單的表單處理 web 應用，沒必要建立 Rich Domain Model。然而，如果你正在編寫一個價值數百萬的企業內聯網架構的核心庫，那麼努力開發一個 Rich Domain Model 就是值得的，它可以為你提供一個準確表達業務過程的平臺，並可以讓你快速傳輸數據。
Martin Fowler 在 PoEAA 中同時簡要介紹了兩種 Domain Model。而 Eric Evans 的 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）。
DomainModel != ViewModel
DomainModel代表著相應的域，但ViewModel卻是為View的需要而創建。這兩者之間或許(一般情況下都)是不同的，此外DomainModel是數據加上行為的組合體，是由複雜的變數類型組成的並且具有層次。而ViewModel只是由一些String等簡單變數類型組成。如果想移除冗餘並且容易導致出錯的ORM代碼,可以使用AutoMapper.如果想要瞭解更多。
那麼領域模型（Domain Model ）和視圖模型（View Model）有什麼不同呢？
在ASP.NET MVC的應用程式中經常可以可以看到View Model，經常我們都認為領域模型和視圖模型是同一個東西。這特別是把領域模型包含在數據傳輸對象DTO里的時候，例如使用Entity Framework之類的ORM工具生成的實體。在這種情況下，領域模型和視圖模型包含的實體非常相似，都是一些簡單的CRUD操作。
這些實體有許多屬性，有相同或類似的名稱，你可以很容易地映射領域實體對應視圖模型中的一個屬性。不過，這些相似的屬性也可能略有不同，例如類型或者格式。例如，用戶填寫的用戶界面的一個屬性，他在視圖模型里可能是一個“Nullable”的。
另一方面，領域實體可能需要一個經過驗證的合法的值，所以需要一個在用戶界面的領域模型之間的轉換。另一個例子是，用戶界面可能會顯示一個滑塊，用於用戶選擇多少天以後提交他的訂單。在這種情況下，視圖模型可能使用一個整數屬性來表示，領域模型通常是一個日期值。
視圖模型通常只包含領域模型的一個子集，而且只包含界面上所需要的屬性。此外，視圖模型可能是一個領域模型樹的扁平版本，例如，一個Customer實體有一個Address，而這又是一個整體，它包含街道地址，郵政編碼，國家等。一個Customer 視圖模型用於顯示數據，將地址數據拉平填充到視圖模型類里。
此外如果一個View需要同時處理幾個領域模型，View Model就是這幾個Domain Model的總和。領域模型和視圖模型之間有很多相似的地方，我們經常乾脆就把Domain Model當作View Model來使用了。
上面討論了領域模型和視圖模型的相似性，我們來看看都有幾種方式把領域模型轉換為視圖模型，通常有3種方法：
- 把領域模型當作視圖模型來用，也就是領域模型就是視圖模型，大部分都是這麼用的。
- 視圖模型裡面包含一個領域模型，定義一個視圖模型，裡面包含了一個領域模型，通過屬性方式進行訪問。
- 將領域模型映射到視圖模型，領域模型並沒有直接映射到視圖模型，需要處理這種映射關係。
我們不建議直接把領域模型實體暴露給視圖，因為有許多細微之處，可能導致您混合業務和表示層的邏輯，無論是領域實體的屬性顯示還是業務的驗證規則，這都是應用程式處理的不同方面。
直接將你的領域模型作為Conroller上的處理參數面臨著安全風險，因為Controller或者Model binder必須確保屬性驗證和用戶不能修改她自己不能修改的屬性（例如，用戶手動更新了一個隱藏的輸入值，或增加一個額外的屬性值，而這個並不是界面上的元素，但卻正好領域模型實體的屬性，這種風險叫做“over-posting”），即使對當前版本的領域模型做了正確的驗證，領域模型將來可能做了變更修改，並沒有出現編譯錯誤或者警告，可能導致新的風險。
我們應當避免使用前兩種方法將領域模型轉換成視圖模型，推薦使用第三種方法，定義單獨的視圖模型類。做這種領域模型到視圖模型的轉換工作是一種重覆性的工作，已經有幾個工具可以幫助你來完成這項工作。最常用的一個工具就是.NET 社區的開源項目AutoMapper。
（個人理解：針對域模型與視圖模型，有時候需要看具體的業務場景，一般情況下可以按照上述將DomainModel和ViewModel進行數據映射，以避免一些安全性問題；但是也可以將DomainModel當成ViewModel來使用也是可以的，通過在系統實現、業務邏輯操作和判斷上是可以保證業務安全性的。就是前者也要進行判斷以保證安全性。所以，還是看具體業務系統的使用環境與要求來決定採用哪種方式來實現。）
文章轉載自：http://www.cnblogs.com/shanyou/archive/2010/04/03/1703501.html
