不同观点：DTO与领域对象

作者 Jonathan Allen 译者 张龙 发布于 2011年6月27日

领域

企业架构,

运维 & 基础架构,

架构 & 设计,

语言 & 开发

主题

WCF ,

Web服务 ,

SOA ,

.NET ,

数据访问 ,

REST ,

企业架构 ,

数据库 ,

ORM ,

编程 ,

架构

分享到

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

译者 张龙 热衷于编程，乐于分享，对新技术有强烈的探索欲，对Java轻量级框架有一定研究。

相关厂商内容

保持某些系统的高可用性，是一些企业的重中之重，如何设计？

海量数据处理，海量视频分发，架构热点难点，尽在架构师峰会！

相关赞助商

ArchSummit全球架构师峰会报名启动！7折优惠，5月31日截止！

1. 返回顶部

   分享：Silverlight 之 MVVM！

   发表人 高 翌翔

   不久前的几个月里一直在参与一个基于Silverlight和WCF的项目，当引用WCF服务成功后，VS会自动生成代理类及若干相关DTO类文件。在MVVM模式中，DTO被视为Model，进而它会被组合到相应的ViewModel中以便绑定时使用，最后ViewModel被设置为View（UserControl）的DataContext。其中，ViewModel恰恰起到了转换层的作用。而调用WCF接口仍会传入Model即DTO，从而有效避免了不必要的数据转换工作。

   回复

2. 返回顶部

   Re: 分享：Silverlight 之 MVVM！

   发表人 lian zhao

   所谓自动生成的代理类是怎么来的呢？还不就是data contract。所以这里讨论的DTO具体到wcf的情况我认为就是data contract。作者的观点在这种情况下就进一步的编程了：领域模型不应该是data contract。

   回复