DTO 形状：扁平、复杂/嵌套或两者的混合

Question

我有一个使用 DDD 方法（域驱动设计）的 MVC2 n 层应用程序（DAL、域、服务、MVC Web），具有带存储库的域模型。我的服务层使用请求/响应模式，其中请求和响应对象包含 DTO（数据传输对象）以将数据从一层编组到下一层，并通过 AutoMapper 的帮助完成映射.我的问题是：DTO 通常应该采用什么形状？它也可以有嵌套/复杂 DTO，还是应该严格地是一个平面投影？ 或者可能两者兼而有之？另外，扁平 DTO 与更复杂/嵌套的 DTO 的主要原因是什么？

例如，假设我有一个域，如下所示：

public class Employee
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public Company Company { get; set; }
}
public class Company
{
    public string Name { get; set; }
    public string Address { get; set; }
    public string City { get; set; }
    public string State { get; set; }
}

我想到了三种不同的方式来建模 Response 对象。

选项 1 - DRYest 选项：

public class GetEmployeeResponse
{
    public class EmployeeDTO { get; set; } // contains a CompanyDTO property
}

根据我所做的研究，DTO 采用与上述领域对象相似的形状是不合适的。

选项 2 - 域的扁平投影（反 DRY）：

public class GetEmployeeResponse
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string CompanyName { get; set; }
    public string CompanyAddress { get; set; }
    public string CompanyCity { get; set; }
    public string CompanyState { get; set; }
}

这更简单，就像 DTO 显然应该的那样，但最终会产生更多的 DTO。

选项 3 - 两者兼而有之：

public class GetEmployeeResponse
{
    public EmployeeDTO Employee { get; set; }
    public CompanyDTO Company { get; set; }
}

这使代码更加枯燥、可重用和可管理，并且不会将我的域结构暴露给最终用户。另一个主要好处是其他响应，如GetCompanyResponse 可以简单地返回CompanyDTO，而无需复制所有这些属性，类似于选项2。你怎么看？您采取和/或为您工作过这些选项中的哪个（如果有）？如果这些请求/响应后来暴露为 WCF 服务方法，你的答案会改变吗？

Answer 1

我个人的偏好是尽量保持平稳，只传输所需的数据。话虽如此，我过去曾使用过深度嵌套的 DTO，因为它在当时很有意义并且符合要求。所以我想它归结为“它取决于”。归根结底，选择对手头的应用程序有意义的东西。试图将数据硬塞进不符合您要实现的目标的 DTO 约定是没有意义的。