如何有效地使用DTO对象(数据传输对象)?

时间:2009-02-04 19:22:23

标签: asp.net design-patterns oop dto

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

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

其他选项怎么样,比如将数据作为方法参数发送? (这是最容易发送的数据吗?)

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

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

感谢您分享您的想法。

6 个答案:

答案 0 :(得分:10)

我用DTO来:

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

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

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

答案 1 :(得分:3)

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

答案 2 :(得分: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

答案 3 :(得分:2)

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

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

答案 4 :(得分:1)

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

答案 5 :(得分:0)

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

摘要+我对此的看法:

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

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

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