DTO与值对象和POJO比较
本文想澄清DTO与Value Object与POCO的区别，其中DTO代表数据传输对象，而POCO是Plain Old CLR Object，在Java环境中也称为POJO。
对Value Object做一个注释：C＃中有一个类似的概念，即Value Type。它只是对象如何存储在内存中的实现细节，我不打算触及它。这里将讨论的是DDD概念中的值对象Value Object。
DTO，Value Object和POCO等概念经常互换使用。但他们真的是同义词吗？
- DTO是一个代表一些没有逻辑的数据的类：DTO通常用于在单个应用程序中的不同应用程序或不同层之间传输数据。您可以将它们视为愚蠢的信息袋，其唯一目的是将此信息提供给收件人。
- Value Object是领域模型的完整成员：它符合与实体相同的规则。Value Object和Entity之间的唯一区别是Value Object没有自己的标识。这意味着具有相同属性集的两个值对象应该被视为相同，而两个实体即使它们的属性匹配也不同。
值对象确实包含逻辑，通常它们不用于在应用程序边界之间传输数据。
- POCO（Plain Old CLR Object）是一个术语，类似POJO，因为“POJO”本身不能在.NET中使用，因为其中的字母“J”代表“Java”。因此，POCO具有与POJO相同的语义。
POJO的主要目标是显示可以成功建模，但不会使与执行环境相关的数据表等发生复杂关系（JavaBeans在其早期版本中带来了很多复杂性如EJB）。执行环境根本不应该与领域建模有任何关系。
对于.NET中的JavaBeans没有直接的比喻，因为微软从未引入过相同的概念，但我们可以提出一些并行的方法来帮助表达这个概念。
您可以将System.ComponentModel命名空间中的Component类视为POCO的反面。.NET中有很多继承自Component的类，例如System.Data的DBCommand和System.Diagnostics的EventLog。
当然，在大多数情况下，您不会创建继承自Component的域类。它没有任何意义，因为这种方法带来了许多不必要的复杂性，因此与YAGNI原则相矛盾 。
另一个非POCO方法的好例子是4.0版之前的Entity Framework。每个EF生成的类都继承自EntityObject基类，因此带来了很多特定于Entity Framework的复杂性。从4.0版开始，Entity Framework引入了POCO数据模型，该模型允许使用不从EntityObject继承的类。
也就是说，POCO代表领域对象使用尽可能简单的类。这一概念有助于符合YAGNI，KISS和其他最佳实践。POCO类可以包含逻辑。
DTO vs Value Object vs POCO：相关性
DTO和Value Object代表不同的概念，不能互换使用。另一方面，POCO是DTO和Value Object的超集。
换句话说，Value Object和DTO不应该继承任何重量级的企业组件，因此它们是POCO。同时，POCO是一个更广泛的集合：它可以是值对象，实体，DTO或您可能创建的任何其他类，只要它不会遗漏您域中的意外复杂性。
请注意，POCO可能都有自己的身份，也没有自己的身份。它取决于它的POCO类型：值对象或实体。此外，POCO可能包含也可能不包含逻辑。这取决于天气与否POCO是DTO。
总结
以下内容总结这个主题：
1、DTO！=价值对象 2、DTO⊂POCO 3、值对象⊂POCO