不同观点:DTO 与领域对象

  • Jonathan Allen
  • 张龙

2011 年 6 月 27 日

话题:SOA.NETRESTDevOps语言 & 开发架构

自从 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

SOA.NETRESTDevOps语言 & 开发架构