POCO vs DTO

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

DTO =数据传输对象

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

POCO和DTO是一样的吗？

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

Answer 1

POCO遵循OOP的规则。 它应该（但不必）有状态和行为。 POCO来自POJO，由Martin Fowler（ 这里有趣的故事）创造。 他使用POJO这个术语来使它更加性感，拒绝框架沉重的EJB实现。 POCO应该在.Net中使用。 不要让框架指定你的对象的devise。

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

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

虽然您可以将POCO看作是DTO，但是如果您这样做，则会冒着创build贫血域模型的风险。 此外，由于DTO应该被devise为传输数据，而不是表示业务领域的真实结构，所以在结构上存在不匹配。 这样做的结果是DTO往往比你的实际域更平坦。

在任何合理复杂的领域中，创build单独的域POCO并将其转换为DTO几乎总是更好。 DDD（域驱动devise）定义了反腐败层 （ 这里的另一个链接，但最好的办法是买书 ），这是一个很好的结构，使隔离清晰。

Answer 2

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

所以，总结一下，要学会去爱POCO，并且确保你不要传播与DTO相同的错误信息。 DTO是用于在应用程序的各个层之间移动数据的简单数据容器。 POCO是完整的业务对象，其中一个要求是持久性无知（没有获取或保存方法）。 最后，如果你还没有签出吉米·尼尔森的书，从你当地的大学里拿出来。 它有C＃中的例子，这是一个伟大的阅读。

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

Answer 3

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

POCO是否有行为是无关紧要的。

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

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

在典型的洋葱式结构中（通常在广义的DDD方法中使用），领域层被放置在中心，所以它的对象不应该在该层之外具有依赖关系。

Answer 4

我为这个话题写了一篇文章： DTO vs Value Object vs POCO 。

简而言之：

• DTO！=值对象
• DTO⊂POCO
• 价值对象⊂POCO

Answer 5

我认为DTO可以成为POCO。 DTO更多的是关于对象的使用，而POCO更多的是对象的风格（与build筑概念分离）。

POCO与DTO不同的一个例子是当你在你的领域模型/业务逻辑模型中谈论POCO时，这是一个很好的面向问题域的OO表示。 您可以在整个应用程序中使用POCO，但这可能会产生一些不良的副作用，例如知识泄漏。 DTO例如用于UI通信的服务层，DTO是数据的平面表示，并且仅用于向UI提供数据，并且将改变传达回服务层。 服务层负责将DTO的双向映射到POCO域对象。

更新马丁福勒说 ，这种方法是一个沉重的道路，只有在域层和用户界面之间存在显着的不匹配时才应该采取。

Answer 6

这里是一般规则：DTO ==邪恶和过度devise的软件的指标。 POCO ==好。 “企业”模式已经摧毁了Java EE世界中很多人的大脑。 请不要在.NET域重复错误。

Answer 7

DTO的主要用例是从Web服务返回数据。 在这种情况下，POCO和DTO是等价的。 从Web服务返回时，POCO中的任何行为都将被删除，因此它是否具有行为并不重要。

Answer 8

别叫他们DTO。 他们被称为模型 ….期间。 模型从来没有行为。 我不知道是谁想出这个愚蠢的术语DTO，但它必须是一个.NET的东西是我所能想到的。 想想MVC中的视图模型，同样的大事情，模型用来在服务器端或者服务器端之间传递状态，它们都是模型。 属性与数据。 这些是你通过电线的模型。 模型，模型模型。 而已。

我希望DTO这个愚蠢的术语会远离我们的词汇。