DTOs与序列化持久实体

Question

我很想知道社区对此主题的感受。我最近遇到了一个N​​Hibernate/WCF场景（实体持久存在于服务层）的问题，并意识到我可能会在这里走错方向。

我的问题很明显，当在Web服务（本场景中的WCF）后面使用持久对象图（NHibernate，LINQ to SQL等）时，您更喜欢通过电线发送这些实体吗？或者你会创建一组更轻的DTO（无循环引用）？

Answer 1

DTO。使用AutoMapper进行对象到对象的映射

Answer 2

我几乎总是创建dtos来通过线路传输并在我的服务器和客户端上使用richter实体。在客户端，他们将拥有一些常见的表示逻辑，而在服务器上他们将拥有业务逻辑。 dtos和实体之间的映射可能是愚蠢的，但它需要发生。像AutoMapper这样的工具可以帮助你。

Answer 3

如果您问我是否将序列化实体从Web服务发送到外部世界？那么答案肯定是否定的，如果你这样做，你将获得最小的互操作性。 DTO通过定义一组“对象”来帮助解决这个问题，无论您使用的是C＃，Java，Javascript还是其他任何语言，都可以用任何语言实例化这些对象。

Answer 4

我以前曾经多次出现过这种情况，可以从双方的经验谈起。最初我只是序列化我的实体并按原样发送它们。从功能的角度来看，这样做很好，但我越是仔细研究它，就越意识到发送的数据比我需要的要多，而且我失去了改变任何一方的实现的能力。在后来的服务应用程序中，我创建了DTO，其唯一目的是从Web服务中获取数据。

任何互操作性之外，不必考虑所有正在通过网络发送的领域是非常有帮助的（对我来说），以确保我不发送是不需要或者更糟的数据，不应该下到客户端。

正如其他人所提到的，AutoMapper是实体到DTO映射的一个很好的工具。

Answer 5

我一直有问题通过电线发送nHibernate对象。特别是如果你使用ActiveRecord模型。和/或如果你的对象与会话有关系（yuck）。另一个令人讨厌的结果是，nHibernate可能会尝试在方法的入口处加载对象（在你可以到达之前），这也可能导致问题。

所以...在这里得到消息？问题，问题问题... DTO的一路