表现层与应用层之间是通过数据传输对象（DTO）进行交互的，数据传输对象是没有行为的POCO对象，它 的目的只是为了对领域对象进行数据封装，实现层与层之间的数据传递。为何不能直接将领域对象用于 数据传递？因为领域对象更注重领域，而DTO更注重数据。不仅如此，由于“富领域模型”的特点，这样 做会直接将领域对象的行为暴露给表现层。

需要了解的是，数据传输对象DTO本身并不是业务对象。数据传输对象是根据UI的需求进行设计的，而不 是根据领域对象进行设计的。比如，Customer领域对象可能会包含一些诸如FirstName, LastName, Email, Address等信息。但如果UI上不打算显示Address的信息，那么CustomerDTO中也无需包含这个 Address的数据

简单来说Model面向业务，我们是通过业务来定义Model的。而DTO是面向界面UI，是通过UI的需求来定义的。通过DTO我们实现了表现层与Model之间的解耦，表现层不引用Model，如果开发过程中我们的模型改变了，而界面没变，我们就只需要改Model而不需要去改表现层中的东西。



所谓DTO就是数据传输对象（Data Transfer Object），POCO就是简单CLR对象（Plain Old CLR Object），概念来源于Java中的POJO；不过值对象（Value Object）并非.NET中的值类型（Value Type）的实例对象，而是领域驱动设计（Domain-Driven Design，DDD）中的概念。那么这三者是什么关系呢？Vladimir Khorikov专门发表了一篇文章来解释这个问题。

首先，他给它们进行了更加准确的定义：

  • DTO是表示数据的对象，但是其中不包含任何业务逻辑
  • 值对象是一个完整的领域模型，不仅包含数据，还有逻辑
  • 从值对象还引申出实体对象（Entity），实体对象和值对象的概念比较接近，只是实体对象一般会基于标识ID要区分两个实例
  • POCO概念来源于POJO，POJO概念由Martin Fowler（我还有幸和他一起共进过两次晚餐）提出，是JavaBeans这种重量级企业构造件对象的对立概念，也即这种类不继承于任何对象（或者说直接继承于Object）；同理，POCO可以看作是继承自System.ComponentModel命名空间中的Component对象的对立对象，或者是EF 4.0之前必须继承于EntityObject基类的实体对象的对立对象。可以说，理解了非POCO的概念，也即理解了POCO概念。
  • 而POCO代表了可以用于领域模型的尽可能简单的对象，而POCO是可以包含逻辑的。

根据以上定义，我们得到这样几个结论：

  • POCO是DTO和值对象的超集
  • DTO不能等同于值对象
  • DTO和值对象都不能有标识Id，而POCO可以有标识Id