将 DTO 对象深度集成到代码中是一种好习惯吗？答案

【问题标题】：Is it good practice to have DTO objects deepy integrated in code?将 DTO 对象深度集成到代码中是一种好习惯吗？
【发布时间】：2010-06-18 23:11:52
【问题描述】：

我正在构建一个相当大的应用程序，它利用 DAO/DTO 设计模式从数据库中获取数据。在应用程序中，特定的 DTO 已成为“核心数据结构”，因为它在整个项目中都被引用。我想知道在整个项目中如此深入地集成这个 DTO 是否是一种好习惯，还是应该有某种转换层来将 DTO 转换为非 DTO 对象？

我可以看到支持和反对使用此转换层的原因。例如，如果我们确实有转换层，那么： 1) 对 DTO 的剧烈更改可能会导致整个项目出现错误，因此转换层将错误隔离到代码中的单个点。 2) 我能够向核心数据结构添加额外的逻辑，因为它是自动生成的，所以无法添加到 DTO。

但是，我也看到了转换层的缺点：1) DTO 转换代码必须在 DTO 更改时保持一致。这增加了程序员必须注意的另一个步骤，因此更容易出错。 2）这也会导致代码重复，因为在大多数情况下，您正在复制 DTO 的访问器。

最好的路线是什么？无处不在的 DTO 还是转换层？那里的任何人都可以指导我正确的方向吗？

【问题讨论】：

标签： oop dto

【解决方案1】：

我认为这个名称会泄露其意图：数据传输对象。数据传输。

DTO 背后的想法是，您可以使用它们来封装您在域模型之外发送的数据，例如发送到另一层。你没有暴露你的逻辑，你只是在发送一些数据。

如果您的域对象是 DTO，则要么将域逻辑暴露在域模型之外，要么将域逻辑保留在域对象之外的某个位置。或两者兼而有之。

我参与过将它们分开的项目，也参与过将它们混合在一起的项目。我真的不建议混合它们。您的图层开始混合，就像扎染一样。

【讨论】：

【解决方案2】：

我认为 DTO 是一种反模式，是 EJB 1.0 持久性如此繁琐以至于需要 DTO 来减少网络流量时的遗留物。

现在我会说创建模型对象并在晚上睡觉。如果可以的话，让它们不可变，不要担心 DTO。

为了架构纯度而进行的翻译浪费了 CPU 周期而没有提供太多价值。

【讨论】：

感谢达菲莫的回复。我真的很感激。
然后通过投票并接受答案来表达您的感激之情。这就是这个网站的运作方式。比起你的感激，我更愿意这样做。
他的代表只有 1，所以他不能投票。你应该让他有机会在接受其他答案之前等待其他答案。至少你可以解释如何接受答案而不是嘲笑他。这就是本网站的运作方式 - 阅读常见问题解答 :)
谢谢 Ben，我有一段时间没有阅读常见问题解答了。我来这里太久了，不记得在投票之前我必须拥有多少代表。至于扯皮，只有脸皮极薄的人才会觉得我的cmets冒犯。