复杂的DTO结构

Question

我在SO、书籍和文章上读了很多关于DTO的内容，但我不确定自己是否理解正确。

我们在项目中使用DTO，使它们几乎成为领域对象的属性。因此，我们需要有一个复杂的DTO结构。其中一些类相互扩展，组合，聚合等。

更普遍的问题是：

从另一个DTO继承DTO或在另一个DTO中引用DTO是否正确？

- hgulyan

Answer 1

从另一个DTO继承DTO是正确的吗？

如果它们共享相同的属性，为什么不呢？

在DTO中引用另一个DTO

这样做绝对没有问题，可以考虑以下情况：

public class UserDto
{
    public string Id { get; set; }
    public string Username { get; set; }
    public string Email { get; set; }
    public AddressDto Address { get; set; }
}

public class AddressDto
{
    public string AddressLine1 { get; set; }
    public string AddressLine2 { get; set; }
    public string City { get; set; }
}

请记住，DTO只是一些简单的对象，也就是说它们没有行为（除了获取/设置自己的数据）。从架构的角度来看，DTO遵循与标准类/对象相同的规则，因此如果可能的话，您应该遵循相同的原则。

- James

---

我认为，我应该尽可能地保持DTO的简单性，因此例如，我应该存储其属性而不是引用另一个DTO。在UserDto中，我将拥有addressline1、addressline2和city，考虑到我将使用带有WCF的DTO。 - hgulyan

@hgulyan 如果你想这样做当然可以，但是这种设计方式并不适合我。拥有作为DTO对象本身的属性是完全可接受的（我会说是首选）。WCF应该可以很好地处理序列化。"我读到过一些关于复杂DTO的问题...循环引用"那是别人的实现和模型不同复杂度的问题。在你决定它行不通之前，你需要至少尝试一下。 - James

如果我理解正确的话，您的意思是说，我可以随心所欲地使用DTO对象，主要限制是不存储行为，对吗？ - hgulyan

@hgulyan DTO 的目的是在应用程序的不同层之间传输数据，例如业务层 -> 数据访问层。 “* 主要限制是不存储行为 *” 是的，DTO 不应该有任何业务逻辑行为，它们只是数据容器。 - James

@hgulyan 你好，如果你需要映射大量数据，可以看看 AutoMapper。不客气 :) - James

Answer 2

DTO是用于层间通信的。

我更喜欢简单的DTO，因为它们主要用于告诉持久层（通常是数据访问对象）要存储什么。如果是这种情况，不要选择复杂的DTO。

如果DTO很复杂（即一个DTO具有另一个DTO作为属性），则DAO存储数据所需的复杂性更大。这与DAO成为脱离存储技术的方式的目标相冲突。

因此，如果DTO需要引用另一个DTO，只需将字符串ID用作属性，并为每个DTO保留一个简单的DAO。处理互连DTO的逻辑应该放在使用DAO的服务应用程序或业务对象中。这样，您可以增加代码的重用性。

- Jorge