MVC3應用程序/服務層/存儲庫層/ POCO類/ EF4 - 問題！

Question

我對這個整體設計概念很陌生，在過去幾周的閱讀中，我收集了很多信息，但看起來很分散，並且很矛盾。條款是混合的，我只是很難包圍我的頭腦。

我使用的圖案是這樣的，並假定流量如下：

MVC應用
控制器（S）處理對於給定的視圖的請求/從客戶端的響應。在控制器操作方法內部，他們聯繫服務（服務層）並請求對象構建視圖模型，並將視圖模型中的對象發回。

查看模型
我正在使用強類型視圖模型來往和從意見。

是查看模型DTO的？它們是否應該包含像Name，AddressLine1，Address City等簡單屬性，或者它們是否應該包含複雜屬性，多個對象等。

是視圖模型中的驗證。如果是這樣的話，它會驗證像是必需的字段，字段長度等。然後驗證像用戶名已經存在，或者你需要與服務層中的其他對象交互的地方？

視圖模型只能包含從EF返回的POCO類，還是應該使用AutoMapper？

如果使用AutoMapper和DTO，是DTO的POCO類的克隆嗎？

你會映射控制器，視圖模型還是映射到下面的服務層？

服務
對我來說，服務（S）是存放庫聯繫（一個或多個），以獲得POCO對象從EF後面的對象。這是我所有的商業邏輯。一旦服務將一個對象交給一個存儲庫並保存到EF中，它們就被認爲是有效的對象。它是否正確？

庫
有一個在他們沒有業務邏輯，它們只是用來服務（S）和EF之間傳輸對象。它是否正確？我正在使用通用存儲庫實現Interfaces。那麼你可以擴展通用存儲庫以滿足特殊需求？

關於術語的問題
1）業務對象是否等於域對象？一個域對象包含多少邏輯？

2）域模型是EF模型嗎？我正在使用Model-First方法。

3）依賴注入 - 我應該使用它嗎？我明白它是如何工作的，只是沒有得到真正的好處。我在和Ninject玩。

我認爲社區會從包含代碼示例的所有最佳實踐的某種wiki中受益。那裏有那種東西嗎？很多樣本都非常簡單，許多微軟樣本即使在聲稱時也不會使用這種樣式。

在此先感謝大家誰已經並將幫助我與此。

順便說一句 - 我認爲StackOverflow上需要一點點，「我買啤酒」按鈕旁邊的「接受答案」複選框:)

Answer 1

是視圖模型DTO的？

可以認爲是控制器和視圖之間的一種數據傳輸對象。

他們應該只包含簡單的屬性，如名稱，AddressLine1，地址城市等，還是應該包含複雜屬性，多個對象等

理想的簡單性，但也聚集其他視圖模型但沒有模型（例如：像EF模型）。

是視圖模型中的驗證。

有兩種類型的驗證邏輯：業務驗證（例如用戶名已存在）進入視圖模型的服務層和UI驗證（例如：用戶名是必需的）。

視圖模型只能包含從EF返回的POCO類，還是應該使用AutoMapper？

沒有EF查看模型。視圖模型是具有簡單屬性的POCO類以及指向其他視圖模型的其他複雜屬性。他們還可以包含方法，以正確格式化將在特定視圖上呈現的數據，這些模型用於此目的。

如果使用AutoMapper和DTO，是DTO的POCO類的克隆嗎？

不知道我理解這個問題。

你會映射到控制器，視圖模型還是映射到下面的服務層？

控制器。

對我而言，服務是與倉庫聯繫以從EF獲得POCO對象的對象。這是我所有的商業邏輯。一旦服務將一個對象交給一個存儲庫並保存到EF中，它們就被認爲是有效的對象。它是否正確？

是的。

域模型是EF模型嗎？

如果您使用的是EF代碼第一種方法，那麼是，否則否（如果EF使用EF特定屬性和類污染域）。

它們中沒有業務邏輯，它們只是用來在服務和EF之間傳輸對象。它是否正確？

是的。

我在這裏實現接口與普通的存儲庫。那麼你可以擴展通用存儲庫以滿足特殊需求？

是的，但不要太花哨。通常存儲庫用於CRUD操作。它是應該包含業務邏輯的服務。

是一個業務對象等於域對象？

是的。

多少邏輯應該域對象包含哪些內容？

這將取決於您正在使用的特定項目以及您可以從您或其他人工作的較舊項目中重用的任何現有域邏輯的域邏輯數量。

依賴注入 - 我應該使用嗎？

是的，絕對。

我理解它是如何工作的，只是沒有得到真正的好處

它提供了應用程序的不同層這反過來使他們更容易進行單元測試和其他重用之間弱耦合項目。

我認爲社區會受益於包含代碼示例的所有最佳實踐的某種wiki。

我同意。

有沒有像那樣的東西？

我對此表示懷疑。

順便說一句 - 我認爲StackOverflow上需要一點點，「我買啤酒」按鈕旁邊的「接受答案」複選框

不能同意。