发送数据到客户端的最佳实践是什么：POCO还是DTO？

Question

我正在使用EF 4和POCO开始一个项目。

发送数据给客户端的最佳实践是什么？我应该发送POCO还是应该有一个DTO?

当将与上下文断开连接的实体发送到客户端时，我应该注意哪些问题?

将POCO发送到客户端层是否是推荐实践？

- pdiddy

---

那么自跟踪实体呢？它们可以为服务器端的插入、更新和删除操作节省大量额外工作。不要认为poco具有此功能。我建议您阅读朱莉·勒曼（Julie Lerman）的《编程实体框架》。她探讨了各种选项，包括：poco、dto和自跟踪实体。 - Youp Bernoulli

Answer 1

我认为我们在这里混淆了两个不相关的定义。

DTO或数据传输对象是一种设计模式，您可以使用它在层之间传输数据，并且它们没有行为。Martin Fowler在http://www.martinfowler.com/eaaCatalog/dataTransferObject.html上很好地解释了这一点。

另一方面，我们有POCO或普通旧CLR对象。但是要谈论POCO，我们必须知道它的起源，即POJO或普通旧Java对象。Martin Fowler与两位合作伙伴创造了这个术语，他在http://www.martinfowler.com/bliki/POJO.html中解释了这一点。

因此，POCO可以具有行为和任何您想要的内容。它们是您日常编写的相同普通类，只是给它们起了一个简短易记的名字。

回答您的第二个问题，我认为最好的方法是从业务层向使用它的所有内容（例如：您的服务、网站、桌面应用程序、移动应用程序等）发送DTO。这是因为它们没有行为，在大多数情况下只有属性，因此它们是轻量级的，并且非常适合在服务中使用，当然，它们不会公开您业务的敏感数据。

话虽如此，如果您计划使用DTO，我可以推荐您下载EntitiesToDTOs，这是我最近在CodePlex上发布的Entity Framework DTO生成器，它是免费且开源的。请访问http://entitiestodtos.codeplex.com

- kzfabi

Answer 2

对我来说，使用EF4和POCO的主要原因之一是你不需要使用DTO。我能理解在传统的EDMX文件中使用DTO的情况，因为你的实体可能会非常臃肿，但这并不是现在的情况。

你的POCO显然需要是可序列化的，但发送POCO实体时不应该有任何特定问题，这些问题与使用DTO的情况相同。

- Scott Arrington

---

向客户公开业务模式并不是一种不好的做法吗？对于一些人来说，向外部世界公开业务模式是一种不好的做法...你对此有什么看法？ - pdiddy

对我而言，POCO 应该是非常“朴素”的。如果是这样的话，把它发送给客户端有什么害处呢？你的 DTO 会是什么样子？它们是否几乎完全与 POCO 相似？那为什么要折磨自己呢？当你想消除许多无用信息时，DTO 很好用，但我并不认为如果它们不包含敏感信息就有必要在全球范围内发送 POCO，这并不会造成太大的危害。 - Scott Arrington

这篇文章怎么样：https://dev59.com/7VDTa4cB1Zd3GeqPKp1i - pdiddy

那篇文章是特定于 WCF 的。其想法在于通过将 POCO 实体与 WCF 数据契约分离来获得灵活性。我不反对这个想法，但我在你的原始文章中没有看到任何关于 WCF 的提及。当我使用 WCF 服务时，我经常将“视图模型”作为数据契约对象放在 EF 实体之上。 - Scott Arrington

明白了，在 WCF 场景中，最好不要将 POCO 暴露给客户端。 - pdiddy

Answer 3

我对以上观点持有稍微不同的意见。 我认为在服务器层之外仍然需要DTO或ViewModel。 在实际应用中，有一些视图层仅需要一个领域对象，也就是几乎每个视图都需要多个领域对象。 而所有这些领域对象都被包装在一个DTO或ViewModel类中。 这就是为什么我坚持认为即使它们是POCO，DTO或ViewModel仍然是必需的。

- Ray

Answer 4

我认为EF4实体是业务模型和视图模型的结合体。例如，它们已经默认实现了PropertyChanged。如果需要，部分类可以提供自定义功能。在我的看法中，将实体与自己的安全层进行镜像处理会创建不必要的工作和维护。

我相信业务逻辑和其他所有内容应该分离。然而，在EF4的情况下，这项工作已经为您完成了。尽情使用吧。

- bufferz

---

我决定不使用EF实体，而是使用POCO，因为EF对PI有很好的支持。但还是谢谢你的回答。 - pdiddy