5

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

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

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

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

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

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

4

2 回答 2

4

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

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

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

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

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

于 2010-02-14T08:41:58.170 回答
1

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

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

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

于 2010-02-14T09:23:56.047 回答