POCO vs DTO

POCO = Plain Old CLR（或更好：Class）对象

DTO =数据传输对象

在这篇文章中有一个区别，但坦率地说，我读的大多数博客都是以DTO的定义方式描述POCO：DTO是用于在应用程序的各个层之间移动数据的简单数据容器。

POCO和DTO是一回事吗？

（ps：看看这篇关于POCO作为一种生活方式的伟大文章）

---

POCO遵循面向对象的规则。 它应该（但不一定）有状态和行为。 POCO来自POJO，由Martin Fowler创造[这里有趣的故事]。 他使用术语POJO作为一种方式，使其更加性感，拒绝框架沉重的EJB实现。 POCO应该在.Net的相同环境中使用。 不要让框架指定你的对象的设计。

DTO的唯一目的是转移国家，而不应该有任何行为。 有关使用此模式的示例，请参阅Martin Fowler对DTO的解释。

以下是它们的区别： POCO描述了一种编程方法 （良好的老式面向对象编程），其中DTO是一种用于使用对象“传输数据” 的模式 。

虽然您可以将POCO视为DTO，但如果您这样做，则会冒着创建贫血域模型的风险。 此外，结构不匹配，因为DTO应设计为传输数据，而不是代表业务领域的真实结构。 这样做的结果是DTO倾向于比实际的域更平坦。

在任何合理复杂的领域中，创建单独的域POCO并将它们转换为DTO几乎总是更好。 DDD（域驱动设计）定义了反腐败层（这里的另一个链接，但最好的办法就是购买这本书），这是一个很好的结构，可以明确隔离。

---

由于我已经在我的博客文章中陈述了自己的立场，所以对我来说贡献可能是多余的，但是这篇文章的最后一段总结了一些事情：

因此，总而言之，要学会热爱POCO，并确保您不会传播与DTO相同的任何错误信息。 DTO是简单的数据容器，用于在应用程序的各个层之间移动数据。 POCO是完全成熟的业务对象，其要求是持久性无知（无法获取或保存方法）。 最后，如果你还没有签出Jimmy Nilsson的书，可以从你当地的大学堆栈中挑选它。 它有C＃中的例子，它是一个很棒的阅读。

顺便说一下，帕特里克我读了POCO作为生活方式的文章，我完全同意，这是一篇很棒的文章。 这实际上是我推荐的Jimmy Nilsson书中的一部分。 我不知道它在线提供。 他的书确实是我在POCO / DTO / Repository /和其他DDD开发实践中找到的最佳信息源。

---

POCO只是一个不依赖外部框架的对象。 这是平原。

POCO是否有行为并不重要。

DTO可能是POCO，可能是一个域对象（它通常会有丰富的行为）

通常，DTO更可能为了序列化目的而对外部框架（例如属性）进行依赖性，因为它们通常在系统的边界退出。

在典型的洋葱式架构中（通常在广泛的DDD方法中使用），域图层位于中心，因此它的对象不应该在该图层之外具有依赖关系。

链接地址: http://www.djcxy.com/p/34495.html

上一篇: POCO vs DTO

下一篇: 'POCO' definition