ASP.NET MVC：什麼去哪裏？

Question

我即將開始開發一箇中等規模的ASP.Net MVC應用程序。 我正在設計正確。我打算有以下各層：

• UI層（MVC）
• 服務層
• 庫層
• 數據訪問層

我將使用Unity作爲我的IOC容器和EF4.1代碼首先進行數據訪問。

該應用程序將被拆分爲幾個程序集。我在決定需要哪些程序集時遇到問題 以及在哪裏放置以下內容：

• 實體/域對象例如客戶，發票
• DTO例如CustomerDTO，InvoiceDTO
• 服務接口例如ICustomerService
• 存儲庫接口例如ICustomerRepository
• 服務（服務接口實現類）例如CustomerService
• 存儲庫（存儲庫服務實現類）例如CustomerRepository
• ViewModels例如CustomerViewModel
• 枚舉

我的問題是： 你通常如何分割你的，爲什麼？

編輯：@TheHurt的答案提示。

組件之間的引用是怎樣的，即哪個組件會引用哪個組件？

Answer 1

這是我怎樣處理它：

App.UI組件：

• 的ViewModels進去模型區域。

App.Repository組件：

• 摘要落實具體的存儲庫。
• ICustomerRepository

App.Repository.SQL：

• 具體實現。
• EFCF波蘇斯

App.Services組件：

• 抽象服務。
• ICustomerService
• 的DTO

App.Services.Implementation：

• 具體的服務。
• 的CustomerService

App.Common：

• 共用代碼。
• 枚舉

有跡象表明，我還是掙扎了幾個問題。跨越服務邊界時，您會從EFCF中丟失數據註釋。那麼你必須做服務器端驗證，否則你必須保持視圖模型驗證與存儲庫實體同步。感覺越分層的東西越多，DRY被侵犯的越多。我認爲這對於課程是平等的，儘管當你的視圖模型不直接映射到你的實體時。你可以讓你的視圖模型成爲你的DTO，並把它們投入到Common程序集中，但是如果你需要對你的服務具有超級靈活性，那麼這看起來會讓事情變得非常緊密。

編輯

如果你是想WCF融入你可能會想創建一個非常接近的MVC視圖模型數據合同（或使用合同作爲視圖模型）的組合。你可能不會向世界公開這個服務，因爲這個服務將特定於你的MVC站點的實現，爲公共消費啓動另一個服務。如果你正在做一個WCF服務，你可能想要在服務中擁有所有的業務邏輯，那麼控制器只會處理導航邏輯。請注意，我儘量遠離「金屬」，同時開發一種設計，使我可以在未來將代碼分成不同的層。如果我無法用一張紙向我的經理清楚地解釋各種系統層次，那麼設計很可能過於複雜。如果設計良好的話，Visio的大部分功能都會非常漂亮。

至於事情如何相互引用：UI將引用Serivce（或服務實現，可能不需要，只需將它們全部保存在同一個地方）。服務引用存儲庫。版本庫實現沒有任何內容，因爲它由IOC加載。一切都是普通的。