我正在使用实体框架的分层架构。这是我到目前为止想到的（除 UI 之外的所有项目都是类库）：
Entities：POCO 实体。完全的执着无知。没有参考其他项目。由 Microsoft 的 ADO.Net POCO 实体生成器生成。
DAL：带有上下文类的 EDMX（实体模型）文件。 （生成 t4）。参考：Entities
BLL：业务逻辑层。将在这一层实现存储库模式。参考：Entities, DAL。这是填充对象上下文的地方：var ctx=new DAL.MyDBEntities();
UI：表示层：ASP.NET网站。参考：Entities, BLL+ 配置文件中实体的连接字符串条目（问题#2）。
现在我的三个问题：
- 我的分层方法正确吗？
-
在我的 UI 中，我按如下方式访问 BLL：
var customerRep = new BLL.CustomerRepository();
var Customer = customerRep.GetByID(myCustomerID);
问题是我必须在 UI 的 web.config/app.config 中定义实体连接字符串，否则会出现运行时异常。在 UI 中定义实体连接字符串是否会破坏层的区别？或者说它在多层架构中是可以接受的。
- 我是否应该采取任何额外的步骤来执行更改跟踪、延迟加载等（我所说的等是指实体框架在传统的、1 个项目、非 POCO 代码生成中涵盖的功能）？
感谢并为这个冗长的问题道歉。
BLL：业务逻辑层。将在这一层实现存储库模式
我不太同意这一点。存储库旨在抽象底层数据存储（SQL Server、XML 等）。这是一个数据层问题，而不是业务层问题 - 因此为什么它应该在 BLL 中？
我的分层方法正确吗？
有点儿。 :) 这有点主观，但通常你有：
- Data
- Business
- Presentation
现在，通常这三者会进一步分解。所以在你的情况下我会：
- MyCompany.MyProject.Data（存储库）
- MyCompany.MyProject.Business.Services（调用存储库、应用业务规则等）
- MyCompany.MyProject.Business.Domain 模型（实体）
- MyCompany.MyProject.UI（Web 应用程序）
我是否应该采取任何额外的步骤来执行更改跟踪、延迟加载等（我所说的等是指实体框架在传统的、1 个项目、非 POCO 代码生成中涵盖的功能）？
如果您不使用 POCO（例如您使用默认代码生成）。那么您就无需担心更改跟踪。
至于延迟加载 - 这是您需要做出的决定。我亲自禁用延迟加载，因为我不希望懒惰的开发人员在没有要求时返回一堆记录。
相反，强制调用代码（例如业务/服务）急切加载它需要什么。
如果您使用 ASP.NET MVC 应用程序，并且启用了延迟加载，您的视图最终可能会在渲染时调用数据库，从而破坏 MVC 模式。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
