DTO与领域模型,项目组织

时间:2016-12-20 14:29:31

标签: c# domain-driven-design repository-pattern

我有一个带有存储库,服务层的项目,使用EF6,代码优先的POCO。在CustomerRepository中,我正在做几个返回对象的投影查询。

据我所知,代码优先的POCO将被视为" Domain Models",但是如果我要对不同的模型进行投影查询。该模型考虑的是什么?例如低于CustomerOrderStats。这仍然是域模型,还是应该被视为DTO模型?

实施例

从Repository返回的对象:

public class CustomerOrderStats
{
   public string Name { get; set; }
   public int Count { get; set; } 
}

在存储库中查询

public CustomerOrderStats GetCustomerOrderStats(Guid customerGuid)
{
   return customers
        .Where(c => c.Guid == customerGuid)
        .Select(new CustomerOrderStats 
               { 
                  Name = c.Name,
                  Count = c.Orders.Count()
               };
}

1 个答案:

答案 0 :(得分:5)

它可能是一个,真的。模型与DTO的定义实际上并不是您如何组织任何给定框架,而是该对象在域中表示的内容。如果它具有丰富的功能或业务逻辑,或者是实际业务流程的活跃部分,那么它可能就是一个模型。另一方面,如果只是一个属性容器将值从一个地方移动到另一个地方,那么它可能是一个DTO。

这里的关键是对象是否是业务流程的活动部分。这里一个好的经验法则通常是对象的名称

  • 这是非技术业务团队成员理解的名称吗?
  • 这是一个用来描述企业行为的术语吗? (即使只是业务的一小部分)
  • 它在整个行业中是否具有意义?

DTO通常仅出于技术原因而存在。组件A需要将数据发送到组件B,但该操作是技术操作而不是业务操作。数据只需要转移。作为系统的一部分,它基本上是“自下而上”构建的,因为它满足了低级别的技术需求。

模型描述了业务的一部分。它可以是图表上的一个元素,它以非技术术语定义业务流程,或者封装业务概念。作为系统的一部分,它基本上是“自上而下”构建的,因为它通常由业务描述,然后专门实现以满足该需求。