如何处理和组织不同背景的DTO？

Question

在各种情况下使用简单的DTO时，我经常遇到同样的问题，我总是想知道是否有更好的方法来处理它。

问题是，我有一个业务对象，例如Asset具有一堆属性，子对象和计算字段，其中一些在时间意义上计算起来很昂贵，其中一些在数据amonut意义上很大。我需要在UI的各种屏幕中使用该对象的不同风格，例如

• 在显示层次结构的树中，我不需要显示名称
• 在网格中，我只展示了几个属性
• 在详细信息窗格中，其中有大量可用信息，但仍然只有一些（如映射对象）仅按需显示

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

• 我有一个包含大量DTO类的类爆炸
• 我很难为同一件事AssetDtoForGridInTheOverviewScreenInTheUpperPaneAboveTheSplitter提出不同的名字，更不用说以后再维护了
• 我经常在转换方法中重复自己，因为有很多属性可供大多数的DTO使用但不是所有（因此我可以'将它们放入任何超类并重用转换逻辑）

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

Answer 1

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

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

当谈到类爆炸时，你是否可能使用过于扁平的数据结构？

这很难说，因为DTO自然会包含大量的语义重复，而这些重复根本就不是逻辑重复。例如，即使您具有语义相似的类型，如果一个是ViewModel而另一个是域对象，它们可能共享语义结构，但责任却大不相同。

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

Answer 2

类爆炸的问题是DTO方法所固有的，你可能没有太多可以做的。注意不要将视图模型与DTO模型混合使用。您的DTO只应用于将数据从您的数据层传输到前端而不是用于演示。

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

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