實體框架和3層架構

我有一個三層體系結構程序。問題是：
1.數據訪問是EF的層？
2.如果我想使用表示層的EF生成的實體，那麼我引用數據訪問，但這違反了3層架構的原則。實體框架和3層架構

2011-07-05 croisharp

croisharp當你從表現層或在您的處理程序項目（邏輯），你只是在尋求模型定義（類），你的數據庫存取仍停留在你的數據層參考你的EF模型，所以不用擔心！ – euther

是EF將是您的數據訪問層。藉助EF，您可以使用帶有POCO支持的T4模板，然後您可以將這些POCO提取到單獨的dll中，這將成爲您所有圖層的參考。

2011-07-05 19:08:05 Jethro

+1使用POCO提供所需的抽象級別，確保架構的完整性得到維護。證據？您可以替換數據訪問實施，但保留POCO作爲數據合同。 –

你正在建造什麼類型的應用程序？如果你正在構建一個ASP.NET MVC 3應用程序，你可以將你的View作爲表示層，Model是你的數據訪問（可以使用EF），控制器和/或Action Filter可以包含你的業務邏輯，場景中，您將在表示層使用EF模型，但仍然滿足關注點分離原則。

2011-07-05 19:21:07

我使用netTcpBinding構建wcf服務，但是使用提供web服務軟件工廠的體系結構。這不會是在架構一個錯誤，如果我從服務實現中引用的數據訪問，或者在表示層任何其他應用程序？ – croisharp

我覺得在任何抽象模型的關鍵目標是限制依賴關係，因此，如果你在你的ServiceContract有一個SQL語句，然後我會說，你的服務實現對數據訪問「過於依賴」。但EF本身就提供了抽象。我想爲你建議的是創建一個存儲庫類，從你的EF上下文中抽象出你的服務。我是否回答你的問題？ –

當然，我與經理的抽象，它執行刪除，編輯，GetById，GETALL，添加方法，但這是業務邏輯，我的意思是這是像客戶，製片人產生的實體... – croisharp

EF做了兩兩件事： -

1）生成您的域模型（可選的，但通常使用的） 2）爲您提供查詢/經由域模型修改數據庫的能力。

這可能會模糊領域模型和數據訪問之間的界限，但兩者確實是分開的。

只要你沒有在創建對象上下文和直接在你的演示文稿中編寫查詢這樣的東西，你就不會破壞抽象 - 你唯一需要「分手」的事實就是你需要引用除非您按照Jethro建議的路線將您的域模型生成到單獨的項目中，否則您的演示項目中的System.Data.Objects（或任何EF dll）（這只是一個物理工件）。

2011-07-06 08:16:08

微軟西班牙發佈在CodePlex上n層應用的一個很好的文件，指導和示例應用程序，你可以看看它在這裏：

您將多個方向和樂於助人的實現模式有找。

hth。

2011-07-06 08:18:35 UrbanEsc

對於三層架構。我會考慮使用領域模型和數據模型模式進行抽象，而不是從表示層直接進行EF。

所以這個想法是，你有你的數據模型有EF POCO類與知識庫知道如何訪問這些類的各種CRUDs。

您的域模型將有與您的客戶端相關的模型（因此您可以放置各種ViewModels或驗證相關代碼），它可以是WPF或MVC Web應用程序。現在，這兩者之間有一個業務與域和數據模型進行對話。

您的表示層對EF /數據層/存儲庫一無所知。當你想引入新的數據框架或數據庫時，你只需要編寫新的存儲庫類和數據模型類（這可能與某種代碼相關）。

這也允許你的代碼也是單元可測試的。

2011-07-06 10:08:10 daehaai

回答