我期待在我們的ASP.NET MVC應用程序中實現洋蔥結構。我理解需要將視圖模型與域實體分開，但是我發現自己正在編寫冗餘代碼。有冗餘的代碼，因爲我的視圖模型和域實體看起來與我的視圖模型具有[Serializable]數據註釋的異常完全相同。我需要這些可串行化的模型，因爲我使用的是ASP.NET會話狀態，其中狀態服務器需要對象可序列化。洋蔥體系結構：我們應該允許我們的域實體中的數據註釋嗎？
我個人覺得域實體不應該是可序列化的，因爲它會變得依賴於特定的技術。但是，我怎樣才能避免冗餘代碼？
我應該補充說我的服務方法依賴於這些可序列化的數據模型。
我會避免註釋與任何持久性或非域相關的我的域對象。這樣，我的Domain項目就不會依賴於另一個圖層，而且我也不會讓它與與域無關的事情混雜在一起。雖然我們需要彎曲規則，但我更願意以不依賴於持久性細節的方式來彎曲它們。
問題的關鍵在於讓各個層面集中在他們的目的上，因爲它很容易混合並創建（及時）大泥球。
就你而言，我感覺你並沒有真正擁有豐富的域名，或者它的建模不當。看起來你只有數據結構，你的需求是CRUDy。
如果您確定應用程序不會變得越來越複雜，即它只是數據結構操作，那麼您可以讓一個模型將其用於所有目的。基本上，你可以偷工減料，並使用'商業'模式來處理所有事情。不需要抽象和其他東西。
但是，如果您認爲應用會發展或者它們將會或將會是業務規則和流程，即您需要對業務所感知的行爲進行建模，那麼最好保持事物非常分離，即使在此階段他們似乎是相同的。
爲了方便起見，對於您的視圖模型，您可以定義一個（使用複製粘貼）並使用automapper將業務對象映射到視圖模型。其他方法可能是您的查詢服務/存儲庫/對象可以直接返回該視圖模型（將查詢結果映射到視圖模型）
+1。這實際上是我試圖解釋給另一個面臨一個稍微不同的問題的人[那裏]（http://stackoverflow.com/questions/28357087/infrastructure-mobility-via-onion-architecture-practical-implications/28362609 ＃28362609） – MaxSC 2015-02-12 08:41:01
視圖模型可以包含域實體/模型。我的域實體是部分類，並且全部（最終）從序列化的基本實體繼承。由於我在我的一些視圖模型中使用了我的域模型，所以我也在域模型上使用了數據註釋。你的域模型庫不應該依賴/引用其他任何東西（域驅動）。
因爲它是核心.Net平臺（mscorlib.dll）的一部分，所以我不會將[Serializable]本身稱爲數據註釋。數據註釋是指用於在ASP.Net或Entity Framework中執行數據驗證和其他操作的specific attributes。
實體應該是[Serializable]？可能不會，但我不認爲這個屬性像來自外部的，面向Web或持久性的庫的其他屬性那樣「摻雜」到您的域圖層。它不會將您與特定的第三方框架聯繫起來。
整個「冗餘代碼」問題取決於IMO所建立的系統類型。在一個真正的DDD應用程序中，域實體和視圖模型之間的重複可能不會那麼公然，而單獨的表示模型的好處通常會超過成本。關於這個問題的好文章：Is Layering Worth The Mapping？
您可以始終考慮通過可以序列化和反序列化您的域對象的工廠模式添加服務。 – IdahoSixString 2015-02-10 15:34:29
我在我的個人項目中使用帶有DDD的洋蔥結構（端口和適配器），我的視圖模型很少看起來像我的域模型。另外，當我爲客戶做以數據庫爲中心的項目時，我會在所有圖層中看到它們使用相同的EF模型，因此我必須聆聽由此導致的數十個問題。 – 2015-02-11 09:07:23
@MickyDuncan一個模型對任何非平凡的非CRUD應用程序都是不利的。它迫使你將不同的用例（關注點）放到一個地方，最終你會得到一個frankenstein的怪物。隨着時間的推移，這些模型會以不同的方式演變，因此您需要每層/有界的上下文都有一個模型，以保持您的理智和生產力。很多開發中的問題都是因爲糟糕的設計以及最快/最淺的解決方案。 – MikeSW 2015-02-11 17:53:50