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

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

问题是，我有一个业务对象，例如，

Asset

，它有一堆属性、子对象和计算字段，其中一些计算时间上很昂贵，一些计算数据量很大。我需要在UI的不同屏幕中使用此对象的不同风格，例如

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

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

• 我有一个类爆炸与大量的DTO类
• 对于同一件事，我很难想出不同的名称，比如剥离器上方窗格中的查看屏幕的

  assetdo，更不用说以后维护它们了

• 我经常在转换方法中重复我自己，因为有一些属性是由大多数DTO使用的，而不是由所有DTO使用的（因此我不能将它们放入任何超类并重用转换逻辑）

---

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

这是DTO的一个已知问题。在这本平庸的书中有描述。换言之：DTO是最通用的n层数据访问模式，但它也需要大量的工作

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

当涉及到类爆炸时，可能是您使用的数据结构太扁平了吗

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

---

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

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

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

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

Solution.AssetManagement.Asset

和

Solution.AssetReporting.Asset