如何处理和组织不同环境下的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，另一个是域对象，它们可能会共享语义结构，但具有完全不同的职责。

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

Answer 2

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

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

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