分層應用程序中的共享層中的實體（橫切關注）？

Question

在一個分層的應用程序中，讓你在共享層中定義實體是否好的做法？我想我會在所有圖層中使用它們。還是他們屬於業務層？

MSDN's layered application guideline把業務實體在業務層

的Layered Architecture Sample for .NET放實體共享層

難道是這樣嗎？

• 介紹
• 業務
• 數據
• 共享
  • 實體

還是必須是這樣的

個
• 介紹
• 業務
  • 實體
• 數據
• 共享

做什麼，爲什麼？

Answer 1

我平時組織項目結構如下：

• 演示（MVC應用程序）
  • 儘量保持你的控制器越小越好。不要將任何業務邏輯放入控制器中。在服務接口上繼承而不是具體的實現使用依賴注入。

• 業務層

  • 服務類屬於這裏，他們應該包含所有的業務邏輯
  • 我組相關的服務到文件夾的功能。每個服務都使用實體框架查詢數據庫，並將結果映射到模型（又名視圖模型，表示對象）對象中。所以服務層不返回數據庫實體，但返回POCO類。
    • 共享文件夾中包含有多個服務之間的共享（他們更像是基礎設施的代碼，但我寧願讓他們的業務/服務項目內）

• DAL數據訪問服務層

  • 我更喜歡只使用實體框架而沒有任何其他抽象。有些人使用存儲庫或實現自己的工作單元模式，但我不建議這樣做。實體框架已經實現了工作單元，並使用linq封裝了數據庫選擇，因此不需要更多的抽象。
  • 這層只包含代碼優先類（實體框架的實體）

Answer 2

我會說這取決於如果這些實體包含業務邏輯或沒有。

從分層應用指南：

業務實體也驗證包含的實體 內的數據和封裝業務邏輯，以確保一致性，並實現 業務規則和行爲。

相比之下，Layered Architecture Solution Guidance似乎依靠代碼生成創建實體，它們僅僅是數據的容器很少在他們沒有邏輯。

Rich domain entities傾向於不在共享模塊中，因爲這意味着攜帶大量您不希望每個人都擁有的行爲（想象能夠直接在客戶端操縱業務邏輯......）相反，貧血是輕量級的，並且可能在各處愉快而方便地分佈。

Answer 3

我的方法有點不同。在數據層中，我存儲所有實體，並在共享層中擁有DTO對象（Domain Transfer Objects），它們是實體的精確副本，但沒有實體框架控件。爲了映射對方，我使用了流暢且易於使用的mapper（AutoMapper）。

我不明白爲什麼實體框架不支持接口，只使用實例。