c# - 如何针对不同的上下文处理和组织 DTO？

Question

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

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

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

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

• 我有大量 DTO 类的类爆炸
• 我很难为同一个东西想出不同的名字，比如 AssetDtoForGridInTheOverviewScreenInTheUpperPaneAboveTheSplitter，更不用说以后维护它们了
• 我经常在转换方法中重复自己，因为有些属性被大多数 DTO 使用，但不是被所有 使用(因此我不能t 将它们放入任何父类(super class)并重用转换逻辑)

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

Answer 1

这是 DTO 的一个已知问题。在这本平庸的 articule on MSDN 中有所描述.换句话说:DTO 是最通用的 n 层数据访问模式，但它也需要最多的工作。

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

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

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

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