如何为不同的上下文处理和组织 DTO？答案

【问题标题】：How to handle and organize DTOs for different context?如何为不同的上下文处理和组织 DTO？
【发布时间】：2011-01-16 15:50:45
【问题描述】：

在各种场景中使用简单的 DTO 时，我经常遇到相同类型的问题，我一直想知道是否有更好的方法来处理它。

问题是，我有一个业务对象，例如Asset 有一堆属性，子对象和计算字段，其中一些在时间上计算成本很高，其中一些在数据量上很大。我需要在 UI 的各个屏幕中使用此对象的不同风格，例如

为了能够在这种情况下实现最佳性能，我总是为每个上下文创建不同的 DTO，只包含在该上下文中实际使用的信息子集。虽然是一种资源优化的解决方案，但这会导致几个问题：

我有大量 DTO 类的类爆炸
我很难为 AssetDtoForGridInTheOverviewScreenInTheUpperPaneAboveTheSplitter 这样的同一事物想出不同的名称，更不用说以后维护它们了
我经常在转换方法中重复自己，因为有一些属性被 大多数 DTO 使用，但不是被所有他们使用（因此我可以'不要将它们放入任何超类并重用转换逻辑）

我使用的技术是 ASP.NET SOAP WebServices 和 C# 3.5，但我认为这可能是与语言无关的问题。欢迎任何想法..

【问题讨论】：

【解决方案1】：

这是 DTO 的一个已知问题。在这个平庸的articule on MSDN 中有描述。套用一句话：DTO 是最通用的 n 层数据访问模式，但它也需要大量工作。

您可以使用基于约定的映射来解决您的一些映射问题，例如AutoMapper。

说到类爆炸，会不会是你使用了过于扁平的数据结构？

这可能很难说清楚，因为 DTO 自然包含大量语义重复，结果证明根本不是逻辑重复。例如，即使您有语义相似的类型，如果一个是 ViewModel，另一个是 Domain Object，它们可能共享语义结构，但职责却大不相同。

另一方面，如果您有很多重复在同一个应用层（例如 UI），您可能违反了 DRY 原则。在这种情况下，将最初作为平面数据结构的相关数据封装到单独的类中通常会有所帮助。在我知道的大多数 UI 框架中，您仍然可以将平面显示器数据绑定到分层结构的类。

【讨论】：

【解决方案2】：

类爆炸问题是 DTO 方法所固有的，对此您可能无能为力。注意不要将视图模型与 DTO 模型混合。您的 DTO 应该只用于将数据从数据层获取到前端，而不是用于演示。

随着 .NET 3.5 的出现，您可以选择实现一些基本的、更粗粒度的 DTO，并将您的 ViewModel 替换为可以动态创建 DTO 的匿名类型。我发现这是一个非常灵活的解决方案。

关于您的命名约定，将您的 DTO 分组到场景中并将它们放在相应的命名空间中可能很有用。例如Solution.AssetManagement.Asset 和Solution.AssetReporting.Asset

【讨论】：