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等概念经常互换使用。但他们真的是同义词吗?
1. DTO是一个代表一些没有逻辑的数据的类:DTO通常用于在单个应用程序中的不同应用程序或不同层之间传输数据。您可以将它们视为愚蠢的信息袋,其唯一目的是将此信息提供给收件人。

2. Value Object是领域模型的完整成员:它符合与实体相同的规则。Value Object和Entity之间的唯一区别是Value Object没有自己的标识。这意味着具有相同属性集的两个值对象应该被视为相同,而两个实体即使它们的属性匹配也不同。
值对象确实包含逻辑,通常它们不用于在应用程序边界之间传输数据。

3. 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。

总结
以下内容总结这个主题:

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