以下代码是否违反持久性无知规则

Question

a) 域实体不应该包含与持久性相关的代码，因此它们应该是Persistence Ignorant PI。但假设 Domain Model DM 是使用 Entity Framework 设计的，并假设 service layer 为 执行 CRUD 操作POCO 域实体 通过 Linq-to-Entities，我们认为 服务层 是直接访问 DAL 还是通过 Domain型号：

class CustomerService
{
       public string doSomething( ... )
       {
                ...
                var customer = context.Customers.Where( ... );
                ...
        }
       ...
}

b) 在 DM 中使用 Linq-to-Entities 是否违反 PI 规则？例如，以下Customer 实体是否违反 PI：

class Customer
{
       public string InterestedWhatOtherCustomerOrdered( ... )
       {
                ...
                var orders = context.Orders.Where( ... ); // does this violate PI rule?
                ...
        }
       ...
}

回复卢克·麦格雷戈：

一）

是的，因为它直接引用上下文。更好的方法是 是使用 Customer 上的内部导航属性来执行 同样的动作，

所以导航属性应该联系上下文？！但是由于 导航属性 也存在于域模型中，那么我们难道不能说通过直接联系 上下文，它们也会违反 PI 吗？

b) 根据Fowler 的关于Data Mapper 的PEAA 章节，可以从Data Mapper 中提取领域代码所需的任何方法到接口类中，哪个领域代码然后可以使用。当使用 EF 而不是手写的Data Mapper 时，究竟如何做到这一点，这样我们就不会违反 PI？

谢谢

Answer 1

是的，它直接引用上下文。更好的方法是使用 Customer 的内部导航属性来执行相同的操作，

class Customer
{
       public string InterestedWhatOtherCustomerOrdered( ... )
       {
                ...
                var orders = this.Orders;
                ...
        }
       ...
}

或者为这个函数创建一个单独的查询类。

Answer 2

a) DDD 中有不同风格的服务。域层服务不应引用实体框架上下文，因为它会将域与特定的持久性方式紧密耦合 - 与域实体相同，见下文。相比之下，应用层服务可以使用上下文（例如调用SaveChanges()），因为它知道当前的工作单元以及何时应该持久化事物。

b) 正如 Luke 所说，是的，它确实违反了 PI，因为实体框架上下文是特定于持久性的。在您的实体中，您应该使用与持久性无关的方式来获取所需的订单。

我不太明白您的 InterestedWhatOtherCustomerOrdered() 方法的作用（为什么要返回一个字符串？...），但您可以：

class Customer
{
       public string InterestedWhatOtherCustomerOrdered( ... )
       {
                ...
                var orders = OrderRepository.GetOtherCustomerOrdersByInterest(...);
                ...
        }
       ...
}

前提是Orders 是一个聚合根。如果不是，您可以使用域层服务，该服务转向基础设施层服务进行查询，或者直接从它们自己的聚合根中询问订单。