不同观点：DTO与领域对象

最新推荐文章于 2021-06-05 10:14:22 发布

糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖

最新推荐文章于 2021-06-05 10:14:22 发布

阅读量127

点赞数

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/cpongo4/article/details/89123625

本文探讨了.NET开发者在使用DTO（Data Transfer Object）时面临的封装问题，并提出了三种观点：一是开发转换层，二是将数据视为结构化数据而非对象，三是采用动态类型。作者Mark Seemann认为，将同一类同时用作ORM实体、WCF 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