滴滴涕。直接从存储库读取还是使用实体？答案

【问题标题】：DDD. Read directly from repository or using a entity?滴滴涕。直接从存储库读取还是使用实体？
【发布时间】：2013-09-18 08:16:39
【问题描述】：

我正在为新系统开发后端，我将尝试使用 DDD。我在核心项目中定义了我的 DDD 实体，并使用存储库模式从持久层读取这些实体。

我需要 WCF 服务，以便我的客户可以访问后端。我是否向此 WCF 服务发送/接收 DTO。

假设我有一个典型的 Order, Orderrows 场景。在我的 WCF 服务中，我声明了一个函数

IEnumerable<DTO.OrderRows> GetOrderRowsForOrder(DTO.Order o)

我需要有关如何实施此方法的建议。我有两种不同的选择。

使用我的域对象来读取订单。

Core.Order order = _orderRepository.GetById(o.Id);
IEnumerable<Core.OrderRow> orderRows = order.GetOrderRows();
IEnumerable<DTO.OrderRows> dtos = orderRows.Select(x => x.ToDTO());

return dtos;

直接使用repository读取orderrows。

IEnumerable<Core.OrderRow> orderRows = _orderRowsRepository.GetOrderRowsForOrder(o.Id);
IEnumerable<DTO.OrderRows> dtos = orderRows.Select(x => x.ToDTO());

return dtos;

对我来说，选择 1 看起来更“面向对象”，但选择不是。 2看起来更简单，更有效。

我的问题是，使用 DDD 时应该使用哪一个？这里用DDD合适吗？

（这当然是一个简单的示例，但是如果我需要为订单列表获取 orderrows 怎么办？）

【问题讨论】：

标签： .net wcf domain-driven-design

【解决方案1】：

这取决于你的聚合根：

如果 Order 是包含订单行的聚合根，那么Order 应该有一个属性OrderRows，当您读取订单时该属性将始终被填充。因此，从订单中获取订单行时不会出现“低效率”问题，因为它们已经在内存中。
如果 OrderRow 本身就是一个聚合根，那么 Order 上会有 no OrderRows 属性或 GetOrderRows 方法。相反，您将使用 OrderRowsRepository 获取订单的所有订单行，类似于您在第二个示例中概述的内容。

【讨论】：

【解决方案2】：

我一直在使用数字 2，但最近我的想法也改变了数字 1。这样做的原因是，如果您使用 2，存储库最终会充满各种询问存储库的方法域对象（实体）应该知道并能够回答。用你自己的话说；它更面向对象。

【讨论】：

由于上下文是明确的领域驱动设计，我不同意你的回答。聚合根的定义是这里的决定因素。
我已经阅读了聚合根，这是有道理的。但是我的第二个问题呢，这里用 DDD 合适吗？
@ErikZ：这真的取决于你的应用程序。 DDD 不是您将其应用于应用程序的一小部分的东西。如果您选择使用 DDD，则此选择会驱动您的域模型和周围代码的完整架构。

【解决方案3】：

假设 Core.Order 是您的聚合根，您将已经在其中拥有 OrderRows 的属性，例如

public class Order
{
    public IEnumerable<Core.OrderRows> Rows { get; set; }

}

因此，选择 #1 稍作修改以调用 Rows 属性而不是使用 GetOrderRows() 进行查询是合适的。

Core.Order order = _orderRepository.GetById(o.Id);
IEnumerable<Core.OrderRow> orderRows = order.Rows;
IEnumerable<DTO.OrderRows> dtos = orderRows.Select(x => x.ToDTO());

return dtos;

【讨论】：