在分层架构实体框架 [英] Entity Framework in layered architecture

问题描述

我使用实体框架分层架构。这是我来到了现在什么了，直到（除了UI的项目是类库）：

• 实体：该POCO实体。完全持久性无知。没有参考其他项目。微软的ADO.Net POCO实体发生器产生。




• DAL ：本EDMX（实体模型​​）与上下文类文件。 （T4生成）。参考文献：实体




• BLL ：业务逻辑层。将实现此层上存储库模式。参考文献：实体， DAL 。这是ObjectContext中被填充其中： VAR CTX =新DAL.MyDBEntities（）;




• UI ：在presentation层：ASP.NET网站。参考文献：实体， BLL +连接字符串进入实体配置文件（问题＃2）。

现在我的三个问题：

1. 是我的层discintion的做法是否正确？



2. 在我的UI，我访问BLL如下：结果
   VAR customerRep =新BLL.CustomerRepository（）;结果
VAR的客户= customerRep.GetByID（myCustomerID）;

   问题是，我必须定义在我的UI的web.config / app.config中的实体连接字符串，否则我得到一个运行时异常。是定义在UI有所斩获的ConnectionString层区别实体？或者是在木里分层架构accesptible。



3. 我应该采取任何其他步骤（通过等我的意思是实体框架涵盖了传统的，1个项目的特点，非POCO code代）进行跟踪CHAGE，延迟加载等？

感谢和道歉冗长的问题。

解决方案

  

BLL：业务逻辑层。在这一层将实施库模式

我真的不同意这种说法。存储库是为了抽象的底层数据存储（SQL Server中，XML等）。这是一个数据层的关注，没有业务一部 - ？因此，为什么要在BLL

  

是我的层discintion的做法是否正确？

类。 :)这是一个有点主观的，但一般有：

• 数据
  
  
  
  • 库放在这里。
  
  


• 业务
  
  
  
  • 业务规则，域逻辑和实体。
  
  


• presentation
  
  
  
  • UI / Web应用程序。
  
  

现在，通常这三个被进一步分解。所以你的情况我将有：

1. MyCompany.MyProject.Data（库）


2. MyCompany.MyProject.Business.Services（Call的资料库，应用业务规则等）


3. MyCompany.MyProject.Business.DomainModel（实体）


4. MyCompany.MyProject.UI（网络应用）

  

我应该采取任何其他步骤来执行CHAGE跟踪，延迟加载等（由等我的意思是实体框架涵盖了传统的，1个项目，非POCO code代功能）？

如果不使用POCO的（例如你使用默认的code代）的。那么你并不需要担心更改跟踪。

至于延迟加载 - 这是你需要做出决定。我的亲自的禁用延迟加载，因为我不想偷懒开发商返回一串记录时，他们并没有要求它。

相反，强制调用code（例如业务/服务）的渴望负载的它需要什么。

如果您使用的是ASP.NET MVC应用程序，如果你有延迟加载，您可以查看最后调用数据库，在渲染时，打破了MVC模式。

I am using a layered architecture with the Entity Framework. Here's What I came up with till now (All the projects Except UI are class library):

• Entities: The POCO Entities. Completely persistence ignorant. No Reference to other projects. Generated by Microsoft's ADO.Net POCO Entity Generator.

• DAL: The EDMX (Entity Model) file with the context class. (t4 generated). References: Entities

• BLL: Business Logic Layer. Will implement repository pattern on this layer. References: Entities, DAL. This is where the objectcontext gets populated: var ctx=new DAL.MyDBEntities();

• UI: The presentation layer: ASP.NET website. References: Entities, BLL + a connection string entry to entities in the config file (question #2).

Now my three questions:

1. Is my layer discintion approach correct?

2. In my UI, I access BLL as follows:
   var customerRep = new BLL.CustomerRepository();
var Customer = customerRep.GetByID(myCustomerID);

   The problem is that I have to define the entities connection string in my UI's web.config/app.config otherwise I get a runtime exception. IS defining the entities connectionstring in UI spoils the layers' distinction? Or is it accesptible in a muli layered architecture.

3. Should I take any additional steps to perform chage tracking, lazy loading, etc (by etc I mean the features that Entity Framework covers in a conventional, 1 project, non POCO code generation)?

Thanks and apologies for the lengthy question.

解决方案

BLL: Business Logic Layer. Will implement repository pattern on this layer

I don't really agree with this. Repository is meant to abstract the underlying data store (sql server, xml, etc). It's a data layer concern, not a business one - therefore why should it be in the BLL?

Is my layer discintion approach correct?

Kind of. :) It's a bit subjective, but generally you have:

• Data
  • Repository goes here.
• Business
  • Business rules, domain logic, and entities.
• Presentation
  • UI/web application.

Now, usually those three are broken up further. So in your case i would have:

1. MyCompany.MyProject.Data (Repository)
2. MyCompany.MyProject.Business.Services (Call's repository, applies business rules, etc)
3. MyCompany.MyProject.Business.DomainModel (Entities)
4. MyCompany.MyProject.UI (Web app)

Should I take any additional steps to perform chage tracking, lazy loading, etc (by etc I mean the features that Entity Framework covers in a conventional, 1 project, non POCO code generation)?

If your not using POCO's (e.g your using default code generation). Then you don't need to worry about change tracking.

As for lazy loading - that is a decision you need to make. I personally disable lazy loading, because i don't want lazy developers returning a bunch of records when they didn't ask for it.

Instead, force the calling code (e.g the business/service) to eager load what it needs.

If your using a ASP.NET MVC application, if you have lazy loading on, your View could end up calling the database at render time, breaking the MVC pattern.

这篇关于在分层架构实体框架的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！