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

问题描述

我在实体框架中使用分层架构.这是我到现在为止的想法(除 UI 之外的所有项目都是类库):

• 实体:POCO 实体.完全执迷不悟.不参考其他项目.由 Microsoft 的 ADO.Net POCO 实体生成器生成.

• DAL:带有上下文类的 EDMX(实体模型)文件.(t4 生成).参考:实体

• BLL:业务逻辑层.将在这一层实现存储库模式.参考:实体，DAL.这是填充 objectcontext 的地方:var ctx=new DAL.MyDBEntities();

• UI:表示层:ASP.NET 网站.参考:Entities、BLL + 配置文件中实体的连接字符串条目(问题#2).

现在我的三个问题:

1. 我的分层方法是否正确?

2. 在我的用户界面中，我按如下方式访问 BLL:
   var customerRep = new BLL.CustomerRepository();
var Customer = customerRep.GetByID(myCustomerID);

   问题是我必须在我的 UI 的 web.config/app.config 中定义实体连接字符串，否则我会收到运行时异常.在 UI 中定义实体连接字符串会破坏层的区别吗?或者在多层架构中是否可以接受.

3. 我是否应该采取任何其他步骤来执行更改跟踪、延迟加载等(我所说的等是指 Entity Framework 在传统的 1 个项目、非 POCO 代码生成中涵盖的功能)?

感谢并为这个冗长的问题道歉.

解决方案

BLL:业务逻辑层.将在这一层实现存储库模式

我真的不同意这一点.存储库旨在抽象底层数据存储(SQL Server、XML 等).这是一个数据层问题，而不是业务问题 - 因此为什么它应该在 BLL 中?

<块引用>

我的分层方法是否正确?

有点.:) 这有点主观，但通常你有:

• 数据
  • 存储库放在这里.
• 业务
  • 业务规则、域逻辑和实体.
• 介绍
  • 用户界面/网络应用程序.

现在，通常这三个被进一步分解.所以在你的情况下，我会:

1. MyCompany.MyProject.Data(存储库)
2. MyCompany.MyProject.Business.Services(调用存储库、应用业务规则等)
3. MyCompany.MyProject.Business.DomainModel(实体)
4. MyCompany.MyProject.UI(网络应用)

<块引用>

我是否应该采取任何额外的步骤来执行更改跟踪、延迟加载等(通过等，我的意思是实体框架在传统的、1 个项目、非 POCO 代码生成中涵盖的功能)?

如果您不使用 POCO(例如您使用默认代码生成).那么您无需担心更改跟踪.

至于延迟加载 - 这是您需要做出的决定.我个人禁用延迟加载，因为我不希望懒惰的开发人员在他们没有要求时返回一堆记录.

相反，强制调用代码(例如业务/服务)急切加载所需的内容.

如果您使用 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 (calls 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 you're not using POCOs (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屋！