我應該放置哪一層.edmx和生成的POCO類？

Question

這是關於EF DB First模型的分層設計。

到目前爲止，我還沒有使用過實體框架，只用實體，並放置在不同的項目使用域/ DTO子文件夾。在DataAccessLayer，業務層和MVC應用程序中也引用了它，並用通常的ADO.Net查詢編寫了一個代碼，併爲我的實體準備了POCO。沒有問題。

現在我們開發使用實體框架DB第一種模式的應用程序。我們選擇了DB First模型，因爲DB Design不在我們的控制範圍內。它由DBA完成。

我想在這裏重新使用舊的簡單設計。但不知道我應該在哪裏/哪一層準確地適合edmx文件和生成的POCO類。我沒有發現任何採用分層架構風格的示例使用DBFirst方法。

我提到這個。 http://aspnetdesignpatterns.codeplex.com但他們使用NHybernate

這裏是老設計的高級概述。

設計/樣本的任何建議，請歡迎您。

編輯：

從下面的答案，我認爲實體框架產生波蘇斯我們可以重命名現有實體/域層，領域層，並把生成的POCO類存在。此外，我們可以簡單地在DataAccessLayer中保留.edmx與IRepository類的列表，將EF包裝爲TDD。這是否使感覺？或任何有價值的點？

更新：

目前我刪除DataAccessLayer並保持其 有model.edmx文件，並通過EF生成的類也實現IRepository所有 庫類唯一實體層。我將其稱爲 業務層，MVC。我做對了嗎？我覺得我在做 設計不好:(請建議/幫助

Answer 1

在我看來，實體框架正確使用否定了一個單獨的DAL的需要。我認爲EF作爲我DAL。它可以讓你專注於商業部分更EF爲您完成所有的數據訪問代碼，你可以簡單地使用你的業務層的EF方面對我來說，這是EF的最好的好處之一;。這是你的DAL

。

取決於你如何（一個組件中的不同組件或不同的文件夾）中分離圖層取決於你在哪裏把你的POCO類。如果不同的組件（這是矯枉過正的大多數項目），然後是「共同」的所有其他組件引用的是去的地方把POCO課程。如果不同的文件夾，那麼一個名爲'Models'或'DomainModels'的文件夾就是這個地方。

特別是對於一個MVC應用程序，我會將我的POCO類放在'Models'文件夾（我也有一個'ViewModels'文件夾）和我的.Edmx放在BLL文件夾中，有時我稱之爲'Logic'。

如果您需要一個鬆散耦合的體系結構進行測試，那麼將EF上下文包裝在您自己的存儲庫模式中的名爲Repositories的文件夾是一種可行的方法。

Answer 2

DAL

• FAL
• SAL
• EF（在這裏你將使用的UnitOfWork上通用的存儲庫（becouse它可以改變，必須尋找性能的情況下））

BL（在這裏您可以根據使用終端使用IOC（Unity或Ninject）隔離此層，如測試...）

• BL可測試DAL經理

MVC

• 模型
• 視圖
• 控制器

單元測試（嘲笑）

我認爲這是最好的米odel

Answer 3

因爲不幸的是，您首先決定創建數據庫會嚴重妨礙您的工作，因此您需要使用Anti-Corruption layer，每Eric Evans' Domain-Driven Design。

這是一個很好的解決方案，當你得到一個絕對必須編碼的低劣接口時，應該怎麼做 - 讓一個接口按照你想要的方式工作。不要將任何EF類直接暴露給除反腐敗層之外的任何東西。

這裏有一個讀例如：

public class SomeReadService : ISomeReadService { 
    public SomeViewModel Load(Guid id) { 
    using (var dbContext = new DbContext()) { 
     // Query the DB model, then *map* the EF classes to SomeVieWModel. 
     // This way you are not exposing the shitty DB model to the outside world. 
    } 
    } 
} 

這裏有一個寫例如：

public class SomeRepository : ISomeRepository { 
    public SomeDomainObject Load(Guid id) { 
    using (var dbContext = new DbContext()) { 
     // Map the EF classes to your domain object. Same idea as before. 
    } 
    } 
} 

我還是會盡量展示給客戶，有一個單獨的團隊設計的數據庫將是一場災難（我的經驗強烈表明它會）。看看是否有某種方式可以提供反饋，向客戶展示如果您設計數據庫，效果會更好。

Answer 4

裹上下文的回購模式，並將其放置在一個文件夾，名爲庫，其中BLL是 ... 肯定的，但用它在上下文的地方（我不與MVC模式同意）通用的，以解決BL中的容器因爲可測性。 是的，你是對的，EF必須是正常的DAL。 模型應該是其他層與所有項目集成，但可能不是poco。 是你的包裝示例解釋通用的存儲庫模式，但也必須有IRepo接口來依賴UnitOfWork（如果需要）。 如果你在域上解析你的分離的BL層，你就可以了。 我覺得智商= 180 :)

Answer 5

請參閱SO鏈接，類似那種以下問題：

With a database-first approach, how do I separate my Core and Infrastructure layers?

希望這有助於！