Question

当我可以将所有业务类放在类库中，在业务逻辑中使用它们，然后将这些相同的业务对象传递给边界类时，为什么要使用DTO / Domain对象？

更新：所有这些都很棒，感谢您的帮助。跟进问题：

您通常在哪里放置这些DTO？与Domain对象一起，即在同一名称空间中？

namespace MedSched.Medical
{
    public class MedicalGroup
    {
        //...
    }

    public class MedicalGroupDTO
    {
        //...
    }
}

Answer 1

DTO为您的域模型提供了一个抽象层。因此，您可以更改模型，而不是违反您为服务客户端签订的合同。这类似于数据库设计中的常见做法，其中视图和过程成为底层数据模型的抽象层。
序列化 - 您可能会过度暴露数据并通过网络发送膨胀的消息。这可以通过使用序列化属性来缓解，但您可能仍然有额外的信息。
隐式与显式合同 - 通过公开域对象，您可以将其留给客户解释其用法，因为他们没有完整的模型可供使用。您通常会根据关联的存在或删除隐式更新域对象，或者盲目地接受所有更改。 DTO明确表达了服务的使用和所需的操作。
断开连接的场景 - 拥有显式消息或DTO可以让您更轻松地实现消息传递和消息传递模式，如Message Broker等。
DDD - 纯DDD要求域对象是外部不可变的，因此您必须将其卸载到另一个对象，通常是DTO。

Answer 2

我可以想到使用DTO的两个基本方案：

您正在从未完成的数据创建业务对象，但验证将失败。例如，您正在解析创建业务对象的CSV文件或Excel文件。如果直接使用这些对象中的数据来创建业务对象，则很可能会失败对象中的多个验证规则，因为来自此类文件的数据容易出错。它们也往往具有与最终业务对象不同的结构：拥有不完整数据的占位符将非常有用。
您通过带宽密集型媒介传输业务对象。如果您使用的是Web服务，则需要在运输前使用DTO来简化对象;否则CLR将很难尝试序列化您的所有数据。

Answer 3

DTO是数据传输对象，传输是关键词。当你想要通过网络传递你的对象并且可能与另一种语言通信时，它们很棒，因为它们“重量轻”（即没有业务逻辑）。

如果您的应用程序不是基于Web服务的，那么DTO实际上并不会为您购买任何东西。

因此，决定使用或不使用DTO应基于应用程序的体系结构。

Answer 4

有时，您要传递的数据不会精确映射到业务对象的结构，在这种情况下您使用DTO。

例如：当您想要传递数据的子集或投影时。