存储库VS在DAL服务模式：EF和小巧玲珑 [英] Repository vs Service pattern in DAL: EF and Dapper

问题描述

我的工作项目，我需要设计的DAL。我将使用实体框架大多数项目和小巧玲珑对于一些性能敏感的领域。

我想使用存储库模式，但随后EF已经实现在某种意义上这种模式。但是，这不是与小巧玲珑的情况。然后，我想知道它是有效的在我的DAL混库和服务模式？或者这会不会越境进入业务逻辑层？

一个样品的结构我想，以打造专业化：

  MyProjectName.Main
    查看/
    控制器/
    基础设施/
    ...
MyProjectName.DAL
    DataService.EF /
        fileName.cs
        ...
    DataService.Dapper /
        fileName.cs
        ...
 

解决方案

EF或任何其他的ORM没有实现存储库。该库是为了从持久脱钩域。域名适用于域对象，EF / NHibernate的/小巧玲珑等具有持久性实体从而重新$ P $工作psents关系数据库的 OOP视图

看到区别？人们需要的业务对象，其他涉及的数据结构。它们是相似的，但它们是不一样的。领域模型的概念，行为和使用的情况下，持久性在乎存储数据，这样正在快速检索。不同的责任。资源库作为中介他们之间，转换域对象持久化的结构，反之亦然。

一直以来，ORM是库的实现细节。对于CRUD应用程序，在那里你真的没有你直接用分贝即中（微）ORM处理域。在这种情况下，回购才有意义，作为幌子，给予一定的商业意义的数据访问（ GetOrders 的是非常容易理解，一个整体的LINQ或5行SQL连接3表）。

存储库接口定义需要的地方，但它的持久性（DAL）来实现。与服务一样，他们可以在域定义（如一个接口），而其实施可以在DAL。虽然仓库实现几乎都是DAL的一部分，只有一些服务驻留在DAL，原因很简单，它更容易为他们做他们的工作的方式。其他服务可以直接使用存储库（通过构造通常注射），不要触摸DAL。

无论您使用的模式，试图了解他们的真正目的，总是想着去耦。

I'm working on project and I need to design the DAL. I will be using Entity Framework for most of the project and Dapper for some performance-sensitive areas.

I was thinking about using the Repository pattern but then EF already implements this pattern in some sense. But that's not the case with Dapper. Then I am wondering is it valid to mix Repository and Service patterns in my DAL? Or would this be crossing into the Business Logic Layer?

A sample structure I was thinking to buid:

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

解决方案

EF or any other ORM doesn't implement the Repository. The Repository is meant to decouple the Domain from the Persistence. Domain works with domain objects, EF/Nhibernate/Dapper etc work with persistence entities which represents an OOP view of the relational database.

See the difference? One needs business objects, the other deals with data structures. They are similar but they are not the same. Domain models concept, behavior and use cases, Persistence cares about storing data so that is fast retrieved. Different responsibilities. The Repository acts as mediator between them, "converting" Domain objects in persistence structures and vice verse.

Always, the ORM is a implementation detail of the Repository. For CRUD apps, where you don't really have a Domain you're dealing directly with the db i.e the (micro)ORM. In that case the Repo makes sense only as a facade to give some business meaning to data access ( GetOrders is much easier to understand that a whole Linq or 5 lines SQL joining 3 tables).

The Repository interface is defined where it's needed, but it's implemented in Persistence (DAL). Same with Services,they can be defined (as an interface) in the Domain while their implementation can be in DAL. While Repository implementation almost always is part of DAL, only some Services reside in DAL, for the simple reason that it's easier for them to do their job that way. Other Services can directly use repositories (injected usually via constructor) and don't touch the DAL.

Whatever pattern you use, try to understand their actually purpose and always think about decoupling.

这篇关于存储库VS在DAL服务模式：EF和小巧玲珑的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！