asp.net-mvc – 存储库与DAL中的服务模式：EF和Dapper

我正在开展项目,我需要设计DAL.我将使用大多数项目的实体框架和Dapper对某些性能敏感的领域.

我正在考虑使用Repository模式,但是EF已经在某种意义上实现了这种模式.但是,Dapper并不是这样.那么我想知道在我的DAL中混合Repository和Service模式是否有效？或者是否会进入业务逻辑层？

我正在考虑的一个示例结构：

MyProjectName.Main
    Views/
    Controllers/
    Infrastructure/
    ...
MyProjectName.DAL
    DataService.EF/
        fileName.cs
        ...
    DataService.Dapper/
        fileName.cs
        ...

解决方法

看到不同？一个需要业务对象,另一个处理数据结构.他们是相似的,但它们是不一样的.域模型概念,行为和用例,持久性关心存储数据,以便快速检索.不同的责任存储库作为它们之间的调解器,“转换”持久化结构中的域对象和对象.

始终,ORM是存储库的实现细节.对于CRUD应用程序,您没有真正拥有一个域,您直接处理数据库即(微)ORM.在这种情况下,Repo只有作为一个立面才有意义,为数据访问提供一些商业意义(GetOrders更容易理解整个Linq或5行SQL连接3个表).

Repository接口被定义在需要的位置,但它在Persistence(DAL)中实现.与服务相同,它们可以在域中定义(作为接口),而其实现可以在DAL中.虽然存储库实现几乎总是DAL的一部分,但只有一些服务驻留在DAL中,原因很简单,因为他们以更简单的方式来完成他们的工作.其他服务可以直接使用存储库(通常通过构造函数注入),并且不要触摸DAL.

无论你使用什么样的模式,试图理解他们的实际目的,并总是考虑去耦.

（编辑：东莞站长网）

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