視圖模型VS域實體

在我開始，我想說的是，我知道一個視圖模型是什麼，它的目的是什麼，但這種情況下使得冗餘..請在:)視圖模型VS域實體

我正在閱讀一個ASP.NET MVC4應用程序，並且遇到了關於PagedList，Domain Entities和ViewModels的一些頭痛問題。

基本上，PagedList.MVC插件不能很好地與AutoMapper配合使用，而且我不得不做一些額外的工作來讓它按照我的需要工作。

但是後來我想，當需要域實體的所有屬性都需要時，我是否甚至需要一個ViewModel類？

當視圖需要域實體上的每個屬性時，ViewModel有哪些好處？

來源

2014-02-20 Ciwan

愚蠢的問題，但你用什麼來訪問你的數據庫？實體框架？如果是這樣，Entity Framework支持可以直接映射到ViewModel的投影。 –

當您的要求或域名實體發生變化，並且它們與您需要顯示的內容不一樣時，那麼是什麼？ –

@BigDaddy，這是一個很好的觀點，但如果這是他需要展示的東西，那麼它可以節省麻煩，福勒稱之爲鳥槍變異的氣味。一個小的改變需要改變許多類。 – dove

它可以是見仁見智的，我喜歡用視圖模式（DTO的和），它提供了以下好處：

我敢肯定，所有的視圖所需要的數據被加載，而不是代理等
如果製作正確的DTO提供一個更小的圖形在一個緩存來存儲（可能並不適用於您的設置）
它讓我的視圖模型從域對象有很大不同，他們往往是複合材料和是非常flatenned，並自由改變它們，而不影響我的應用程序的任何其他部分。

現在爲了解決上述問題，許多人會直接使用您的域對象。如果您發現您的視圖模型只是您的域名的一對一圖片，並且您沒有看到上述任何好處，我也可能會推薦這一點。

像往常一樣，這取決於你的設置

你的團隊
是什麼讓你生產
工具使用ORM如果在所有
規模和項目
經驗
etc等

來源

2014-02-20 14:24:36 dove

所有的觀點都是有效的，但在我的場景中，他們都是靜音的。我想？ – Ciwan

是的，它聽起來像你至少應該嘗試工作，如果它只是在你的方式，我已經添加了一個「它取決於」的答案 – dove

我最近在一個小團隊與開發人員擁有15年以上的經驗。我們的域名和虛擬機中有90％是1對1關係。是的，它創建了一個額外的foreach語句來轉換這兩個，但我喜歡分離。任何支持的想法/爲什麼這樣的1對1傳輸完成的原因 – CSharper

我只想補充說，對於小型項目，只需擁有自己的ViewModel並使用它即可。稍後，您可以在實體需要時分開實體。

對於許多開發者增加新圖層而沒有權衡利弊，後來他們開始注意到滯後疑惑發生。 MVC本身已經是一個分離關注點。

擁有獨立的DomainEntity解決了UI不再將1對1映射到實體的問題，請考慮以下事項。

Version 1 
Domain    | Presentation 
-------------------------------- 
User.FirstName  | User.Name 
User.LastName  | 
User.PositionTitle | User.PositionTitle

該示例演示了域和演示文稿不再以1對1映射。在未來，你可能有域的修改，如下列：

Version 2 
Domain    | Presentation 
-------------------------------- 
User.FirstName  | User.Name 
User.LastName  | 
Position.Title  | User.PositionTitle

基於上面的例子（第2版），請注意，呈現沒有被修改。擁有分離的域模型可以提高界面的穩定性。它甚至可以降低重構場景的更改成本。

優勢的視圖模型

視圖模型的美妙之處在於它能夠消除您的域名從表示，在大型項目中，不同的開發商處理系統的不同部分使用時，這樣的好處是更明顯（獨立GUI團隊）

一個小小的變化需要更改許多類。

這是解耦您的實體的缺點之一，它會創建代碼的重複。額外的編碼具有巨大的成本，其益處顯而易見是值得的。

來源

2014-02-21 05:44:46 Yorro

視圖模型VS域實體

回答

相關問題