数据传输对象（DTO）和数据传输对象之间的区别一个愚蠢的商业对象？

Question

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

Answer 1

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

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

Rockford Lhotka的CSLA.NET方法是在业务对象上使用IsValid()方法，并使用一组已分配给对象本身的规则。还有其他方法可以解决这个问题，但关键是业务对象执行验证。正如您所怀疑的那样，“愚蠢”的业务对象实际上只是DTO。

Answer 2

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

在这种情况下：

• DTO旨在在应用程序层之间传输数据
• Dumb Business Objects是您的域模型的一部分

Answer 3

也许有点多余，但我已经输入它了嘿;）

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

在像PHP这样的弱类型语言中，并不总是需要DTO，因为可以动态地为通用对象赋予任意属性。但它们仍然可用于文档和强类型函数参数。