数据传输对象（DTO）与愚蠢的业务对象之间的区别？

Question

我在我的应用程序中使用了愚蠢的业务对象。只是使用了DTO来转移对象的选定属性，但我想知道两者之间有什么区别？我无法找到任何。

Answer 1

也许有点多余的部件之间传输数据，但我已经输入它如此嘿;）

为了简单化（很多），业务对象应该有getter/setter方法，DTO应该只有属性。业务对象需要遵守业务规则，但DTO仅用于传输数据;他们不需要遵守任何规则，应该尽可能快地设计出数据。

在像PHP这样的弱类型语言中，DTO并不总是必需的，因为可以随意为通用对象提供任意属性。尽管如此，它们仍然可以用于文档，并且可以使用强类型的函数参数。

Answer 2

我只会说，唯一的区别是意图，假设你的哑巴业务对象只持有状态和没有行为。

在这种情况下：

• DTO的旨在应用层
• 哑业务对象是你的域模型

Answer 3

当你说“愚蠢”的业务对象，你有效地使这些对象与DTO一样。使业务对象成为业务对象的是增加了验证和其他功能逻辑。当他说业务对象需要setter和getter方法时，我不同意用户“否”他们可以使用属性就好，他们只需要比任何一个更多。

一个共同的观点是业务对象应该被允许保存无效值，并且只有在试图持久化数据库时才会抛出异常，在这种情况下属性工作得很好。但是，大多数应用程序都希望在尝试发布到数据库之前向用户提供反馈。

罗克福德洛特卡的CSLA.NET方法是在业务对象上使用IsValid()方法，该方法具有一组已分配给对象本身的规则。还有其他方法可以解决这个问题，但关键是业务对象执行验证。正如你怀疑的那样，“愚蠢的”业务对象确实只是DTO。