领域和持久层，与存储库的关注点分离

Question

域层

public interface IRepository<T> where T : MyEntity
{
}

public class Car : MyEntity
{
   ...   
}

public interface IMyCarRepository : IRepository<Car>
{
}

持久层

public class Repository<T> : IRepository<T> where T : MyEntity
{
   public DbContext Context;
   public DbSet<T> DbSet;

   public Repository(DbContext db)
   {
      Context = context;
      DbSet = context.Set<T>();
   }
   ... Crud method implementation from the IRepository
}

public class CarRepository : Repository<Car>, ICarRepository
{
    private CarContext _db;
    public CarRepository(CarContext db) : base(context)
    {       
       _db = db;
    }
}

这工作正常，但正如您所看到的，CarRepository 使用的是域中的汽车模型。 假设我想更改汽车模型以便使用 MyEntityMongo 我会更改 MyEntityMongo 而不是 MyEntity

public class MyEntityMongo
{
   [BsonId]
   public string Id {get; set;}
}

但这个 [BsonId] 会将 MongoDB.Bson.Serialization.Attributes 带来我不想做的对域的依赖。

在不将 Mongo 库引入域（或任何其他相关数据库）的情况下，您将如何做到这一点？目标是保持域和持久层之间的关注点清晰分离？

Answer 1

无论如何，我都不是 C# 开发人员，但我会考虑将持久性实体与域实体区分开来，即 MyEntity 是持久性表示，而其他类型是实体的域表示。

那么，存储库本质上是加载和保存持久性表示到数据库的持久性基础设施与域逻辑之间的适配器（或者甚至可能是反腐败层......）；作为适配器，它在逻辑上依赖于两者。

Answer 2

您可以按照清洁架构 实践。从这个意义上说，存储库接口不属于存储库或数据访问层，而是属于业务逻辑。您应该能够设计和编码应用程序的核心，而无需实现真正的存储库，直到最后。

这在您的示例中具有多种含义：

1. 不要定义通用存储库接口。由于接口属于业务逻辑，因此您将为每个实体定义存储库接口。并非所有实体都需要存储库中的相同方法，因此通用接口通常不是一个好主意。

2. 如果向域对象添加基类，这样做是因为它在域对象设计中有意义，而不是因为持久层需要它。

3. 您的存储库接口将获取并传递域对象，这是核心所需要的。无论存储库接口如何处理它们，从核心的角度来看都是无关紧要的。

对 Core 进行编码和单元测试后，您可以创建在对 Core 进行编码时定义的接口的实际实现。因此，在实现 Car 存储库时，您需要评估 2 个选项：

1. 实体框架：EF 允许您以非侵入性方式将域对象直接映射到数据库（使用 IEntityTypeConfiguration）。因此，您可以使用域对象在 DbContext 中定义 DbSet，并且您的存储库实现变得非常简单，无需额外的映射。在某些情况下，如果您想要或需要与域对象非常不同的数据库结构，您可能仍然需要将域对象映射到数据对象。

2. MongoDb：Mongo 确实可以很好地处理具有映射属性的非常具体的数据模型。因此，您的 mongo 存储库会将域对象来回映射到 Mongo 对象。

Answer 3

在我看来，最好有两个不同的课程。一种用于领域逻辑，另一种用于持久性模型。为什么？这只是我的意见，但因为将来重构代码更简单、更容易。

在我看来，这可以被认为是一个非常主观的问题……我的建议是基于 DDD 实践。

在 DDD 的上下文中，存储库层应该将持久性实体转换为正确的业务实体并返回它。

否则每个服务都会有关于持久性的知识。

Sapiens Works 的更多解释：

• 领域模型模拟现实生活中的问题和解决方案，它模拟
  行为。

• 持久性模型模拟数据的存储内容和方式，它模拟
  存储结构。看？他们有截然不同的目的。这
  域是应用程序存在和万事万物引力的原因
  围绕它。域不应该依赖于任何东西，特别是不依赖于
  持久性实施细节，如 EF 或 NH。当你设计
  领域实体，他们对持久性一无所知。
  持久性、数据库不存在。

还有一点：

当您设计持久层时，该层服务于域
并取决于它。所以持久化需要了解域
但反之则不然。您设计用于存储的持久性实体
目的并匹配 ORM 的约束（例如使所有
属性虚拟）。所以你将拥有域实体和持久性
实体，每个实体都有自己不同的目的和实现。

是的，它们确实相似，有时甚至可以相同（当域
很简单）但这只是巧合。每一个
当你在存储库中建模或使用 ORM 时，你
正在对持久性而不是域进行建模。埃里克是有原因的
埃文斯建议使用域启动应用程序并忽略
任何与数据库相关的内容：域不应被污染
基础设施细节，因为大多数人开始一切
采用以数据库为中心的方法。一旦你开始使用数据库，
一切事物都会围绕它发展，并受到它的制约。但
您不是为数据库构建应用程序，而是为
域，数据库只是一个Persistence的实现细节。