視圖中的域對象

Question

我們一直在討論是否在我們的視圖（asp.net mvc 2）中使用域對象，還是應該將每個需要數據的視圖發送給ViewModel？

我想知道是否有人對這個問題有任何優點/缺點，他們可以闡明一些？

謝謝

Answer 1

我喜歡從我的視圖中分離我的域對象。就我而言，我的域對象僅用於表示應用程序的域，現在是如何顯示應用程序。

表示層不應包含任何域邏輯。他們展示的所有東西都應該由他們的控制器預先確定。確保此視圖始終堅持的理想方法是確保視圖僅接收這些展平的ViewModels。

我自己也問過similar question。下面是我接受的答案報價：

我認爲有功績 其在 域不同的設計比在表示層。 所以在概念上你實際上是 看兩個不同的模型，一個 爲域圖層，一個爲 表示層。 每個型號 都針對其目的進行了優化。

如果我有Customer>Sales>Dispatch Address域對象，那麼我不希望有應對在我看來，物體穿越。我創建了一個包含所有屬性的展平視圖模型。如果您使用優秀的開源項目AutoMapper，那麼在映射到這個扁平化視圖/演示模型時幾乎沒有額外的工作。

此外，如果您可以創建該模型的優化的表示形式，爲什麼還要將整個域對象傳遞迴視圖？

Answer 2

如果您使用NHibernate的或類似的 - 你的域對象很可能是代理，這些序列化工作逼債。您應始終使用ViewModel並將您的域對象映射到您的視圖模型中的DTO。不要在這裏採取捷徑。設定大會將減輕你後來會遭受的痛苦。

這是一個標準模式的原因。

w：//

Answer 3

這取決於。在某些情況下，可以使用模型類的實例。在其他情況下，單獨的ViewModel是更好的選擇。根據我的經驗，在您的域名和視圖中擁有不同的模型是完全可以接受的。或者在視圖中使用域模型。做什麼最適合你。爲每個選項做一個尖峯，看看有什麼可行的，然後決定。您甚至可以爲每個視圖（和/或部分）選擇不同的選項。

Answer 4

肯定會有簡單的小應用程序，可以在所有圖層中使用相同的模型。通常數據應用程序的表單很少。但是對於一個合適的領域，我對這個主題的想法是將領域模型和視圖模型分開，因爲你不希望他們在改變時互相影響。

如果域邏輯需要一些小更改來處理後端的一些新業務邏輯，那麼您不希望改變視圖的風險。相反，如果市場營銷或某人想要對視圖進行更改，則不希望這些更改泄漏回您的域（必須填充字段並保留數據以用於除某些視圖之外的其他目的將要使用的目的）。

Answer 5

目前我有一個很好的比較，因爲我正在使用不同方法的兩個項目。我並沒有說「這很糟糕，這很好」，因爲這是用某種模式寫的。我知道模式，我喜歡模式，但我從不盲目追隨他們，只是爲了正確。我總是使用我目前需要的來實現當前目標。

在第一個應用程序中，使用視圖中的域對象，開發速度非常快。幾個地方几乎沒有變化，你有額外的屬性，形式輸入等。你不打擾層，只是擴展/更改代碼並傳遞到另一個問題。

在第二個應用程序中，這裏總是有對象用於此處，還有其他地方，有幾十個類看起來相同，執行相同操作，以及各種版本的相同對象之間的大量轉換代碼。更糟糕的是，一些開發者在類的「這個版本」上做了一些邏輯，而其他邏輯則在「該版本」上完成。開發是非常痛苦的，需要大量的測試。改變一件簡單的事情需要很多關注，並且需要更改很多代碼。我真的不喜歡這個應用程序，因爲我從來沒有看到這種方法帶來的商業利益，至少在去年（並且我們處於從今年開始的生產階段）。這個應用程序的開發和維護比第一個應用程序貴三到四倍。

所以，我對這個問題的有趣回答是：這取決於。如果你在10-20人的團隊中工作，你喜歡上班，喝幾杯酒，和朋友聊天，做幾件簡單的事，回家後，很多中間物品和轉換代碼都會對你有好處。如果您的目標是快速且便宜，如果您想專注於業務層，新功能，以下快速更改，以及更多如果您觸摸軟件業務並想要爲項目兌現（我們將這些東西都做好，最終出售，對嗎？），第二種方法可能會更好。