不同观点：DTO 与领域对象

自从 NHibernate 与 WCF 出现以来，.NET 开发者们就开始向统一的实体模型概念上不断靠拢。最后的结果就是同一个类可以作为 ORM 实体、WCF DTO 以及 MVC、MVP 与 MVVM 框架的模型。.NET Dependency Injection 的作者 Mark Seemann 认为这不见得是件好事。

问题的关键在于“在边界处，应用并不是面向对象的”。如你所见，大多数序列化技术都要求 public、默认的构造方法以及可写的属性。本质上，在设计 DTO 时，这些要求会迫使你打破封装和数据隐藏的原则。甚至连基本的不变性，如要求字段不为 null/ 不为空都不可能实现，因为 DTO 会忽略掉一切。Mark Seemann 继续证明自己的论断：

• 服务共享模式与契约，而非类。
• DTO 并不会破坏封装，以为他们根本就不是对象。

根据这种情况，Mark 提出了 3 种观点：

第 1 种观点是坚持已有的观念。为了消除隔阂，我们必须得开发一个转换层，用于将 DTO 转换为封装良好的领域对象。这正是书中的示例所采取的方式。然而，我越发觉得这种解决方案并不是最佳的。这会导致可维护性的问题（这也是我写书时所遇到的问题：当你写完后，你所知道的要比刚开始动笔时多不少，我并不是说书不好，只是想说它并不完美而已）。 第 2 种观点是不再将数据当作对象，将其看作是它自身所表示的结构化数据。如果我们所用的编程语言有单独的结构化数据概念就太好了。有趣的是，虽然 C#并没有这个概念，但 F#却有多种方式来建模数据结构而不涉及行为。或许这是更好的数据处理方式，我还要多尝试几次才行。

第 3 种观点是使用动态类型。在文章 Cutting Edge: Expando Objects in C# 4.0 中，Dino Esposito 介绍了通过动态方法来使用结构化数据，这可以更快速地自动生成代码并向结构化数据提供轻量级的 API。这种方法更有前途，它并没有提供编译期的反馈，但这只不过是一种安全上的错觉而已。我们需要通过单元测试来快速获取反馈，但我们一直都在使用 TDD，不是么？

如果你对面向对象设计与封装感兴趣，那就一定不能错过名为 Poka-yoke Design: From Smell to Fragrance 的系列文章。

查看英文原文： Differing Opinions: DTOs vs Domain Objects