2011-12-08 69 views
4

我想弄清楚構建我的解決方案的好方法。我知道我將使用以下技術,Asp.Net Webforms和Entity Framework 4.1。我的EF模型基於現有的數據庫。我打算使用EF DbContext生成器來構建我的上下文和實體。這是事情對我來說有點棘手的地步。在webforms中使用實體框架的正確抽象方法

我想妥善分離關注點,提供更好的可測試性,並允許將我的業務邏輯與DAL分開。我目前在我的解決方案中有三個項目:Web,Core和Data。我希望依賴關係是Web - >核心< - 數據,完全不依賴於Web和數據。這要求我的實體實際上存在於Core中,而不是Data(我的edmx在哪裏)。目前,我的想法是將Entities.tt文件移動到Core,並將inputFile更改爲指向Data中的我的edmx以在Core中生成我的實體。但我不確定如何處理上下文。它很大程度上依賴於EF,因此我不想簡單地將它移入Core。我考慮過連接它,創建自己的IEntities.Context.tt並將其放入Core中。我擔心的是如果我的界面不創建DbSets和DbContext,則會導致功能喪失。我一直對此有兩個想法,1)在Core中放置一個System.Data.Entity的引用,2)不使用DbSet,並用ICollection(或一些這樣的通用容器)替換它幷包裝DbContext作爲我的界面中的一個對象。

任何洞察力將不勝感激。謝謝。

+0

爲什麼你不能讓上下文和Context.tt生成器留在你的數據項目中?我不認爲有必要將它移入Core。 Core當然必須引用數據庫中的上下文。這是你遇到的問題,你不想要什麼?如果是這樣,您將爲應用程序添加一個額外的複雜性和抽象層次,因爲您必須將EF從您的Core中抽象出來(抽象「存儲庫」和「工作單元」模式是通常的方式來執行此操作=關鍵字搜索)。儘管Core引用了數據,事情變得更加容易。 – Slauma

+0

我在想Core不應該依賴於Data,而是提供Data和Web都可以使用的基本POCO對象。這完全將Web從數據中分離出來,並且允許更容易地將數據換出(即:如果我們想要移動到nHibernate或另一個ORM)。 –

回答

0

有很多,你可以使用不同的圖案,但兩人立刻浮現在腦海:

1)添加一個業務/服務層 - 這將您的數據層和表示層之間的抽象。這是我最經常使用的方法 - 使用AutoMapper和依賴注入(我喜歡Ninject)使猴子工作更容易。您的業​​務層將公開其自己版本的數據庫對象(不推薦)或與您的業務模型相關的對象(更強大的方法)。

2)使用控制反轉模式 - 目前非常流行,儘管我還沒有在現實生活場景中給它一個bash。顯然TDD /模擬等非常好......它基本上意味着你的數據層依賴於你的業務層而不是其他方式。我的「核心」或「通用」程序集對我的業務或數據層一無所知 - 它們僅僅提供平臺不可知的幫助程序和公共類 - 例如,如果我想創建常見的MVC功能,例如,我將創建一個Company.MVC.Core程序集。

0

如果你的解決方案是全新的,那麼我喜歡在實體框架中使用代碼優先的方法(原諒無恥的插件,但我已經在我的博客上寫了關於這個http://www.terric.co.uk/code-first-entity-framework-and-sql-migrations/的教程)。我喜歡它給我的控件,當我生成.edmx時,我似乎無法得到它。

移動到結構,我通常我的項目層層分解爲單獨的組件:域(和數據)和WebUI有以下文件夾結構(命名空間):

Domain (business layer and data layer assembly) 
    Data (contains my EF data context and Interface to the context) 
    Entities (contains my POCO objects for the context) 

WebUI (presentation layer assembly) 
    Infrastructure (contains my dependency inject initialiser) 

我從來沒有DI我的實體,而是在我的表示層中使用混凝土,但是我將始終使用DI,因爲我可能希望/必須使用ADO.Net(尤其是傳統應用程序),其中我的域層仍然使用ADO.Net來讀/寫我的POCO實體。通過這種方式,當我最終實現了使用舊版應用程序實現ORM的功能時,我只需簡單地輸入我的域的ORM版本即可。

作爲一個腳註,如果您遵循存儲庫模式,您可以將它們和DI存儲在一起。無論哪種方式,您的POCO應該是特定於解決方案的,因此底層數據結構不會經常發生顯着變化,因此我從不去解析它們。