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

Question

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

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

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

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

• 我有大量的 DTO 类的类爆炸
• 我很难为同一个东西想出不同的名字，AssetDtoForGridInTheOverviewScreenInTheUpperPaneAboveTheSplitter更不用说以后维护它们了
• 我经常在转换方法中重复自己，因为大多数DTO都使用了某些属性，但并非所有这些属性都使用（因此我不能将它们放入任何超类并重用转换逻辑）

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

Answer 1

这是 DTO 的一个已知问题。MSDN 上这篇平庸的文章对此进行了描述。换句话来说：DTO 是最通用的 n 层数据访问模式，但它也需要最多的工作。

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

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

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

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