2

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

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

其他选项呢，比如将数据作为方法参数发送？（这在要发送的数据较少的情况下最容易吗？）

一个只保存数据的静态类，可以被其他对象引用（一种全局汇编数据存储类）呢？（这是否会过多地破坏封装？）

每次传输都使用一个通用 DTO 怎么样？使用起来可能有点麻烦，但减少了需要使用的类的数量（减少了对象混乱）。

感谢您分享您的想法。

4

6 回答 6

11

我使用 DTO 来：

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

“一个 DTO 来统治它们”方法可能会变得混乱，最好的办法是为每个特性/特性组使用特定的 DTO，注意命名它们，以便它们易于在它们所使用的特性之间进行匹配。

我从未以您提到的方式看到过静态 DTO，并且会犹豫创建您所描述的 DTO 单例。

于 2009-02-04T19:31:47.483 回答
3

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

于 2009-02-04T19:27:40.643 回答
3

我希望它可以这么简单。尽管 DTO 源于系统的网络分布层，但如果将域对象返回到视图层，则可能会出现大量问题。这里是其中的一些：

1.通过将域对象暴露给视图层，视图可以了解域对象的结构，这让视图可以对相关对象如何可用做出一些假设。例如，如果域对象“Person”被返回到它“绑定”到的视图，而在其他一些视图上，Person 的“地址”将被绑定，应用程序层将倾向于使用类似的语义person.getAddresse() woukd 失败，因为此时地址域对象可能尚未加载。本质上，随着域对象对视图层可用，视图总是可以对数据如何可用做出假设。

2.) 当域对象绑定到视图时（在胖客户端中更是如此），以视图为中心的逻辑总是会潜入这些对象中，使它们在逻辑上被破坏。

基本上，根据我的经验，我已经看到使域对象可用于视图会产生架构问题，但是使用 DTO 也存在问题，因为使用 DTO 在创建汇编程序（DTO 到域对象和反向）方面会产生额外的工作，类似的对象，例如 Patient 域对象、Patient DTO 以及可能绑定到视图的 Patient bean。

显然，在一个胖客户端系统中，这个问题没有正确的答案。

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

于 2010-07-21T09:37:56.660 回答
2

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

我肯定会说它们使用起来更麻烦。它们确实提供了所有的管道，但是针对它们进行编程是一种痛苦（大量的强制转换、空检查、魔术字符串等）。看到一组很好的扩展方法使使用它们更“自然”会很有趣。

于 2009-02-04T19:41:47.853 回答
1

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

于 2009-05-17T23:23:00.963 回答
0

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

总结+我对此的看法：

--如果要移动的数据量很少，而且要移动的地方不多，则常规参数可能就足够了

--如果有很多数据和/或许多对象要移动到，特别创建的对象可能是最简单的（DTO 对象）。

——一个可以被各种对象引用（而不是传递）的全局数据对象似乎不受欢迎……但是，我想知道在特定的子系统中是否有时没有它的位置？这是减少数据传递量的一种方法。它确实推动了“良好封装”的极限，但是在特定层内的特定实例中，也许它可以为特定的类组合增加简单性。因此，一个人将失去类级别的封装，但仍可能具有程序集级别的封装。

于 2009-02-05T18:28:14.147 回答