如何有效地使用DTO对象（数据传输对象）？

Question

实施DTO的最佳方式是什么？

我的理解是它们是在对象之间传输数据的一种方式。例如，在ASP.Net应用程序中，您可以使用DTO将代码发送到业务逻辑层组件。

其他选项怎么样，比如将数据作为方法参数发送？ （这是最容易发送的数据吗？）

如何只保存数据的静态类，可以被其他对象（一种全局组件数据存储类）引用？ （这会破坏封装吗？）

每次转移使用的单个通用DTO怎么样？使用它可能会有点麻烦，但减少了使用所需的类数量（减少了对象的混乱）。

感谢您分享您的想法。

Answer 1

我用DTO来：

• 在标准3层应用的UI和服务层之间传递数据。
• 将数据作为方法参数传递，以封装大量（5+）参数。

'一个DTO来统治他们'的方法可能会变得混乱，最好的办法是针对每个功能/功能组使用特定的DTO，注意命名它们以便它们之间很容易匹配用于。

我从来没有像你提到的那样看过静态DTO，并且会像你描述的那样犹豫创建DTO单身人士。

Answer 2

我保持简单并将一个DTO类映射到一个db表。它们很轻巧，所以我可以把它们送到任何地方，包括通过电线。

Answer 3

我希望它可以这么简单。虽然DTO源于系统的网络分发层，但如果将域对象返回到View层，则可能会出现全部问题。以下是其中一些：

1.通过将Domain对象公开给View层，Views可以了解域对象的结构，这使得view可以对相关对象的可用方式做出一些假设。例如，如果域对象“Person”被重新调用到它被“绑定”的视图，而在某个其他视图上，Person的“Address”将被绑定，Application层将倾向于使用类似语义的因为那时woukd失败的person.getAddresse（）地址域对象可能还没有被加载。实质上，随着域对象变得可用于视图层，视图总是可以假设数据是如何可用的。

2。）当域对象绑定到视图时（在胖客户端中更是如此），视图中心逻辑会在这些对象内部蔓延，从而使它们在逻辑上损坏。

根据我的经验，我已经看到使View域可用的域对象产生架构问题但是使用DTO也存在问题，因为使用DTO在创建汇编器（DTO到域对象和反向）方面创建了额外的工作。 ，患者域对象，患者DTO以及可能患者bean的类似对象的扩散必然会被观察。

显然，在胖客户端系统中，没有正确的答案。

我借用了这个简短而不完整但真实的答案来回答DTO的陈词滥调：
http://www.theserverside.com/discussions/thread.tss?thread_id=32389#160505

Answer 4

我认为使用DataSet / DataTable作为“一个DTO来统治它们”是很常见的。可以很容易地从数据库加载它们，并将值保留回来，并且可以很容易地序列化它们。

我肯定会说他们使用起来比较麻烦。它们提供了所有的管道，但针对它们的编程是一种痛苦（大量的转换，空检查，魔术字符串等）。看到一套好的扩展方法可以使它们更加“自然”，这将是很有趣的。

Answer 5

DTO用于通过线路而不是对象之间发送数据。看看这篇文章： POCO vs DTO

Answer 6

感谢所有有用的想法...

摘要+我对此的看法：

- 如果要移动少量数据而没有太多移动它的地方，常规参数可能就足够了

- 如果有大量数据和/或许多对象将其移动到，则特别创建的对象可能最简单（DTO对象）。

- 可以被各种对象引用（而不是传递）的全局数据对象似乎不赞成......但是，我想知道在某个特定的子系统中是否偶尔会有它的位置？这是减少数据传递量的一种方法。它确实突破了“良好封装”的极限，但是在特定层中的特定实例中，也许它可以为类的特定组件增加简单性。因此，会丢失类级封装，但仍可能具有汇编级封装。