DTO、Model，ViewModel，Object，Entity作用

DTO、Model和ViewModel是我们经常在应用架构中的持久层、表示层等层次上出现的数据载体，学习OOP的朋友也经常会接触到Object和Entity。在这里我希望与大家交流一下这几个概念。

1.DTO

数据传输对象(DTO)是用来在软件应用子系统之间传递数据模式,DTO经常被用来跟数据访问对象（DAO）一起从数据库查询数据。
既然DTO是一种模式，那么它解决了哪些问题呢？

早期的远程方法调用，此图演示了远程客户端 通过一系列方法访问客户名字的各个元素。

使用了DTO模式之后，远程客户端通过一次请求取得了客户名称DTO，随后在本地调用 实现各个名称元素的访问。

现在这种模式不仅在企业模式的网络边界上运用，还在应用架构的各个层次间有了身影。

2.Model

Model最早在MVC（Model-View-Controller）模型中被引入，实际上内容与Domain Model一致。
领域模型（Domain Model）是在软件工程中引入的一种概念模型，它被用来关联所有的主题数据进而解决指定问题。它描述了各种实体和它们的属性、角色和关系，以及那些问题领域的约束。

Martin Fowler在2003年提出的定义则更为简练：一个对象的领域模型包含对象的数据和行为。

Model是可以应用于DTO模式的，但是出于DTO模式是主要解决数据传输，不太关注行为，所以可能是Model的数据部分和共同功能部分。

3.ViewModel

ViewModel是在MVVM模式（应用于WPF及Silverlight框架）中，在展示层频繁使用的Model。

4. Object、Value Object和Entity Object

Entity Object实际就是Entity，与Value Object不同，Entity都有主键来标识信息的唯一性如个人信息。而Value Object则是可能在系统中重复的，如整个公司人员的邮编或者内线电话，它是不应有主键的。一般系统中对于Entity Object和Value Object的操作策略也不同，例如Entity Object采用更新方式，而Value Object则采用根据其关联的Enity进行整体覆盖的方式进行。

Entity和Model在于设计层次的不同，Entity一般是从数据库设计开始的系统从表映射过来的，所以这个Entity也可以理解为数据实体而非领域模型。而Model则是根据主要问题领域，从业务上开始设计的，数据更新方面可能比Entity更复杂，但是在业务处理上却比Entity更灵活。

个人感觉敏捷开发和业务需求比较弱的系统适合使用Entity，而业务复杂且需求性强的系统，应该采用领域模型进行设计。但并不是绝对划分清楚的，很多系统中都会有两者的身影存在只是解决的问题和方面不同而已。

引用地址：http://www.chawenti.com/articles/5100.html