我正在编写一个网络服务。我还在编写一个使用此 Web 服务的 Web 客户端。我经历过尝试通过网络发送域对象的一些痛苦（循环引用、延迟加载等——参见例如Davy Brion's post on why it's a bad idea）。因此，我将使用 DTO 在这两层之间进行传输。
负责两端，我能够控制 DTO 的设计。现在我想知道，是什么驱动了 DTO 的设计？它是客户端的用户界面吗？我是否根据客户将拥有的视图/屏幕创建 DTO？或者它应该决定我发送的 DTO 的合同的服务方，并且客户端必须使用它给出的东西？
【问题讨论】：
标签： c# web-services dto
我认为在很多情况下DTO模型没有领域模型那么重要，所以我在这个问题上非常务实。我们编写的 DTO 非常接近客户的实际需求，因为它是唯一的消费者。 （有进程调用服务器，它们使用不同的 DTO。）对于数据的不同视图，甚至可能有不同的 DTO。这就是 DTO 的力量。
明确一点：它应该驱动客户的需求，而不是客户特定的。例如，使用通用数据类型，而不是特定于视图的数据类型。并非视图上的每个更改（例如 UI 设计更改）都会导致 DTO 的更改。这是可维护性的一般规则，没什么特别的。
【讨论】：
设计您的 DTO 可能是一项艰巨的任务，尤其是因为涉及到许多问题。通常，性能考虑会阻止您完全从 UI 中抽象出来。假设您对同一个对象有多个 UI 表示，例如树、网格和详细信息窗格。根据您实际显示的内容，它们中的每一个都需要不同的属性子集。您可以设计一个通用 DTO 来包含所有这些属性的联合，但构建这样的 DTO、从存储中加载数据并通过网络传输数据可能会很昂贵。您最终可能会传输包含大量数据的丰富对象图，只是为了在 UI 中显示对象的名称。
另一方面，如果您针对每个 UI 上下文使用 DTO，您很快就会遇到类爆炸问题，其中数百个 DTO 代表几乎相同的对象，并且属性子集略有修改。代码的重用和可读性会受到影响，从长远来看可能会变得难以管理。
由于没有灵丹妙药，它需要一种敏感的方法，您可以找到性能和其他方面之间的折衷方案，可能每个域对象最多使用 3 种不同的 DTO 类型并在不同的上下文中重用它们。
【讨论】：
hejdig.
当我不确定接口时，我通常先编写调用者，因为这样我就有了使用方法的上下文。它让我给方法起一个易于理解的名称和适合方法用户的参数。
/OF
【讨论】：
现在我想知道，是什么驱动了 DTO 的设计？
我个人认为 数据 应该决定 DTO 的设计，它应该完全由 DTO 的目的驱动，即序列化。为此，我将使其成为具有简单 get/set 属性的完全平面数据结构。您要做的最后一件事是通过让表示层问题发挥作用来损害 DTO（简单）目的的完整性。
【讨论】：