c# - DTO 与领域模型、项目组织

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

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

我知道代码优先的 POCO 被认为是“领域模型”,但如果我要对不同的模型进行投影查询,该模型是什么? CustomerOrderStats 就是一个例子。这仍然是领域模型,还是应该被视为 DTO 模型?

例子

从存储库返回的对象:

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()
               };
}

最佳答案

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

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

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

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

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

关于c# - DTO 与领域模型、项目组织,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/41244638/

相关文章:

java - 存储库上的事务

c# - DataContext 的生命周期,LinqToSql

c# - 使用 Graph API 将图像从 .NET 发布到 Facebook 墙

c# - 在 Linux 上运行 .NET Core——什么都不写

domain-driven-design - 如何处理在 DDD w/Clean Architecture 中具有太多依赖参数的 UseCase Interactor 构造函数?

c# - DDD 值对象相等,== 与 .Equals()

c# - 同时支持 MS-SQL 和 Oracle

使用 Entity Framework 6 异常数据读取器的 C# 存储库模式 SQL 查询与指定实体不兼容

c# - 如何跳过printDocument.print()中的打印对话框,直接打印页面?

c# - 单个查询比 3 个查询慢