c# – 分层架构中的实体框架

发布时间：2020-12-15 06:57:19 所属栏目：百科来源：网络整理

导读：我正在使用具有实体框架的分层架构.这是我到现在为止(除了UI之外的所有项目都是类库)：实体：POCO实体.完全坚持无知.否参考其他项目.由Microsoft的ADO.Net POCO实体生成器生成. DAL：具有上下文类的EDMX(实体模型)文件. (t4生成).参考文献：实体 BLL：业务

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

>实体：POCO实体.完全坚持无知.否参考其他项目.由Microsoft的ADO.Net POCO实体生成器生成.
> DAL：具有上下文类的EDMX(实体模型)文件. (t4生成).参考文献：实体
> BLL：业务逻辑层.将在此层上实现存储库模式.参考文献：实体,DAL.这是objectcontext被填充的地方：var ctx = new DAL.MyDBEntities();
> UI：表示层：ASP.NET网站.引用：实体,BLL连接字符串条目到配置文件中的实体(问题#2).

现在我的三个问题：

>我的图层是否正确？
>在我的用户界面中,我访问BLL如下：
var customerRep = new BLL.CustomerRepository();
var Customer = customerRep.GetByID(myCustomerID);

问题是我必须在我的UI的web.config / app.config中定义实体连接字符串,否则我得到一个运行时异常. IS定义UI中的实体连接字符串破坏了图层的区别？或者是在多层次的建筑中可以使用.
>我应该采取任何其他步骤来执行chage跟踪,懒惰加载等(等等,我的意思是实体框架在常规的1项目,非POCO代码生成中涵盖的功能)？

谢谢并道歉的漫长的问题.

解决方法

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

我真的不同意这个.存储库旨在抽象底层数据存储(sql server,xml等).这是一个数据层的关注,而不是一个业务 – 因此,为什么要在BLL中？

Is my layer discintion approach correct?

有点. :)这有点主观,但一般你有：

>数据

>存储库到这里.

>业务

>业务规则,域逻辑和实体.

>演示

> UI / Web应用程序.

现在,通常这三个进一步分解.所以在你的情况下,我会有：

> MyCompany.MyProject.Data(Repository)
> MyCompany.MyProject.Business.Services(Call的存储库,应用业务规则等)
> MyCompany.MyProject.Business.DomainModel(Entities)
> 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)?

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

至于懒惰加载 – 这是你需要做出的决定.我个人禁止懒惰加载,因为我不想让懒惰的开发人员在没有要求的时候返回一堆记录.

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

如果您使用ASP.NET MVC应用程序,如果您有延迟加载,您的View可能会在渲染时最终调用数据库,从而破坏MVC模式.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!