转自大神loveis715博文：http://www.cnblogs.com/loveis715/p/4379656.html
在一个web服务的实现中，我们常常需要访问数据库，并将从数据库中取得的数据显示在用户页面中。这样做的一个问题是：用于在用户页面上显示的数据和从数据库中取得的数据常常具有较大区别。在这种情况下，我们常常需要向服务端发送多个请求才能将用于在页面中展示的数据凑齐。
一个解决该问题的方法就是根据不同需求使用不同的数据表现形式。在一个服务实现中较为常见的数据表现形式有MO(Model Object)和DTO(Data Transfer Object)。MO用来表示从数据库中读取的数据，而DTO用来表示在网络上所传输的数据。
why DTO?
无论是桌面应用还是web服务，其内部的数据表现都是非常重要的。在初学者了解一个系统时，其首先需要了解各个组件在系统中的作用，然后再了解系统中的workflow，即在执行业务逻辑时各个组件是如何协同合作的。在了解了这两部分后，初学者需要做的事情就是仔细的梳理一遍数据是如何在整个系统中流动的，即 是整理和理解数据流(dataflow)的过程。而在真正了解了数据流之后，该初学者才具有了在系统中开发的能力。
整理数据流的过程是一个逐步细化的过程：从鉴别数据结构到该数据结构中每个属性到底是如何使用的。在整个数据流中，任何一个属性值的改变都可能会导致数据的处理方式发生变化。
在整理数据流的时候我们要做什么事情呢？首先我们需要鉴别出到底哪些数据会在各个组件之间进行传送，在传送过程中进行了什么转换，这些数据是如何构建出来的，又由它构建了哪些数据，最终这些数据是否被持久化到本地存储中等等。
而在整理数据流的过程中，数据的转化常常是最难理解的部分。一个数据类型的定义常常与其运行环境有关。例如在一个电子商务网站中，一个表示商品的类Product可能包含了该商品的所有信息：商品的名称、品牌、详细介绍、价格等。在用户使用电脑浏览器浏览的时候，这些信息都将被显示在页面上。但是用户用手机进行浏览的时候，我们就需要考虑如何为这些手机用户节省一些流量。一种节省流量的方法就是首先显示商品的简略信息，并在用户决定查看商品的详细介绍时再从服务端下载商品的详细信息。这种情况下包含商品所有信息的类Product将不再是适合传输的数据结构。
而问题不仅出在需求将数据结构拆分的情况，更有可能出在数据合并的情况中。例如网页的UE为了提高用户体验，要求在产品页中直接将该商品品牌的详细信息显示在页面中。在这种情况下，我们就需要在表示的类Product中添加一个记录该商品品牌的域brand。但是在数据库中，表示商品的类Product可能仅仅记录了商品品牌的ID。因此在业务逻辑中，我们就需要将Product和其对应的Brand合并在一起。
甚至说，我们可以将事情弄得复杂一些：
在上面的图中，我们展示了数据在一个系统中可能存在的多种不同表现形式。在图片的中央位置是一个服务器，多种客户端都将从它那里获得产品信息。就像前面所说，为了节省客户端的流量，服务端向移动客户端所发送的数据将是产品信息在服务端的简略版本。而在一个浏览器访问该产品的时候，表示商品品牌的信息将内嵌在产品信息之中，以提供更好的用户体验。除了与客户端通信，服务端之间也可能产生信息的交换。在该交换过程中，表示产品的Product以及表示品牌的Brand则彼此独立的在服务端之间传递。而就一个运行在远端的Agent而言，其可能仅仅需要一个Product的ID来监控产品在生产制造方面的状态。
而这一切数据都应从系统的数据库中得到。数据库中的数据不可能同时存储并维护这一系列数据结构，因此在一个复杂的系统中，数据库中的数据表示与系统中所传输的数据之间常常是不同的数据结构。常见的情况则是将其分为两类：一类用来访问数据库，在系统中表现数据库中所记录的数据，叫MO，即Model Object；另一类用来在网络中传输，叫DTO，即Data Transfer Object。
服务中的DTO和MO：
在了解了我们为什么需要DTO和MO等数据的不同表示后，就让我们来看看这些数据表示在一个web服务中是如何工作的。
先让我们从最简单的web服务分层开始说起。一个最简单的web服务主要分为数据访问层(DAL)，业务逻辑层和表现层三个部分。其中表现层是运行在客户端的，而其他两个则运行在服务端。当数据从DAL层读取出来的时候，其所记录的数据与数据库中所记录的数据是一致的，因此它们就是我们这篇文章中讨论的MO。而在传输给客户端的时候，这些数据可能会和MO不同，因此称其为DTO。
现在就让我们放大一下数据访问层，来看看数据访问层中MO所在的位置：
首先要强调的是，实现数据访问层的方式有很多种，而上图所展示的仅仅是一种基于Repository模式的实现。通过Repository来实现DAL是一种最为常见的数据访问层实现方式。就像上图所展示的，在一个基于Reposityory模式的实现中，数据访问层将拥有一系列Repository实例。这些Repository实例依赖于系统所使用的ORM来将数据库中的数据转化成java类实例。这些java类实例实际上就是在该数据访问层所提供给业务逻辑层的MO。
而DTO则用于在服务与客户之间以及服务与服务之间进行数据的传递。在这些传递过程中，对DTO的需求可能是多种多样的：
上面的图片展示了一段Product这种类型的DTO在服务端和客户端以及服务端之间进行交互的过程。在该流程中，所需要传递的DTO并不相同：在使用浏览器读取和保存有关的Product的信息时，两者的数据变现形式可能会有一些细微的差别。而在保存完毕后，服务可能会将新的Product作为负载来向其他服务器发送请求，而此时所使用的Product的表示又可能与前两者略有区别。如果为这些细微的差别定义很多不同的DTO，那么系统对数据的管理可能会遇到一系列麻烦。例如在一个复杂的系统中，DTO可能会按照下面的方式在系统中流转：
在上图中，我们展示了一个DTO在依次流转过多个服务的情况。如果在DTO依次传递的过程中使用了不同的DTO表示，那么一个服务所拥有的DTO可能和另一个服务中所拥有的DTO并不匹配。这边是DTO反过来会影响到架构设计的一个最简单的例子，却也是DTO管理中最常见的问题，那就是DTO的变现形式过多。如果为所有的不同需求都创建一个DTO，那么一个概念所对应的DTO可能多达5、6种，非常难于管理。这种管理上的困难常常存在于如何指定某个服务所需要使用的DTO种类，以及在更改DTO时需要同时修改一系列DTO的情况中。
为了防止DTO由于不同的需求而衍生出过多的种类，服务实现中常常允许DTO中的数据包含一些冗余。
逐步添加你的DTO：
那么我们该如何向系统中添加DTO呢？答案是，根据情况决定。在项目的一开始，数据库中所存储的数据与页面所需要显示的数据常常是一致的，因此在这种情况下我们并不需要DTO的帮助。而在所需要的数据和数据库所记录的数据不再一样的时候，我们就需要考虑是否需要在项目中添加DTO了。这时软件开发人员就需要问自己：这种所需要的数据与数据库中的数据不一致的情况是否常常出现？如果答案是“是”，那么我们就需要开始着手准备添加对DTO的支持。
在系统中添加DTO主要有以下几部分工作需要完成：
1）添加DTO类；
2）添加从MO到DTO的转化逻辑；
2）将原本对MO的使用转换为对DTO的使用。
相信读者最先注意的就是第三点。可以想象的是，如果将整个系统的MO替换成DTO，那么它的影响面将会非常大，而且非常容易出错。因此在一个大型项目中，我们常常需要预先判断DTO的必要性，进而尽早的添加DTO。
让我们回过头来看看第一个任务应该如何完成。在一个系统中，DTO常常用来传输数据，因此其自身往往不带有任何逻辑。这也是DTO常常被定义为javabean的原因。以javabean的形式来定义DTO带来了一个巨大的好处。那就是很多第三方类库都提供了生成Javabean的功能。在这种情况下，软件开发人员只需要通过一系列描述性语言来描述这些DTO即可。这其中最常用的就是JAXB。
在使用JAXB的时候，开发人员只需要在.xsd文件中编写一系列描述性信息：
<xsd:complexType name="Address">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="street" type="xsd:string"/>
<xsd:element name="city" type="xsd:string"/>
<xsd:element name="state" type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="country" type="xsd:NMTOKEN" fixed="US"/>
</xsd:complexType>
那么在JAXB运行完毕后，相应的java类就将被生成：
@XmlAccessorType(AccessType.FIELD)
@XmlType(name = "Address", propOrder = {
"name",
"street",
"city",
"state"
})
public class Address {
protected String name;
protected String street;
……
@XmlAttribute
@XmlJavaTypeAdapter(CollapsedStringAdapter.class)
protected String country;
public String getName() {
return name;
}
public void setName(String value) {
this.name = value;
}
public String getStreet() {
return street;
}
public void setStreet(String value) {
this.street = value;
}
……
public String getCountry() {
if (country == null) {
return "US";
} else {
return country;
}
}
public void setCountry(String value) {
this.country = value;
}
}
是不是很简单？在知道如何创建一个DTO之后，我们就需要考虑如何将MO转化成为DTO。当然，这依然有第三方工具可以帮助我们完成这个事情。一个较为著名的工具就是Dozer，使用Dozer也很简单，在它的配置文件里面标明需要互相转换的两个类型即可：
<mapping>
<class-a>com.ambergarden.egoods.mo.Address</class-a>
<class-b>com.ambergarden.edoods.dto.Address</class-b>
</mapping>
在运行时，Dozer会使用反射来对这两个类型中的各个同名属性进行匹配并赋值。如果两个类型中拥有不同名的属性，那么开发人员可以显式的指定相互匹配的属性：
<mapping>
<class-a>com.ambergarden.egoods.mo.Address</class-a>
<class-b>com.ambergarden.edoods.dto.Address</class-b>
<field>
<a>name</a>
<b>owner</b>
</field>
</mapping>
除此之外，Dozer还支持非常多的转化功能，在这里就不一一介绍了。
在有这些工具的辅助下，为系统添加DTO已经变得简单多了，在对DTO的日常维护中，我们可能需要添加一些新的DTO或者更改已有的DTO。在这种情况下，我们只需更改对DTO进行描述的文件并更新Dozer的配置文件即可。当然，如果Dozer中使用了自定义转换逻辑，那么开发人员还需要更新相应的转换逻辑。
贫血的DTO：
DTO中只包含数据，并没有包含任何行为。“这我知道”或许你会说。
但是千万不要大意。这常常会导致你陷入贫血模式的陷阱中。在服务端的业务逻辑实现以及客户端的页面逻辑中，我们有时需要指定对这些数据的操作逻辑。从面向对象设计的角度来说，某些逻辑实际上就应该定义在这些类型中。但是由于DTO本身没有定义这些逻辑，因此我们需要在这些类型之外定义它们，例如在一个helper类中为这些类型定义一系列辅助函数。
一个最简单的示例就是对数据有效性的检查。例如在一个Person类中，我们使用一个整型数据记录该任务的年龄：
class Person {
private int age;
……
}
那么在业务逻辑中，我们就需要检查该域是否被设置为负数。由于DTO是使用工具自动生成的，因此这些检查逻辑无法放在该DTO类中。作为一种变通方式，我们需要写一个辅助类来实现该功能。但随着这种需求越来越多，对这些辅助功能的管理将越来越困难。因此你就将完全陷入到贫血模型的陷阱中。
也就是说DTO的主要职责是为了传输数据，但它并不擅长，甚至是不适合在业务逻辑中表示一个复杂概念。一个复杂概念常常与一些可重用的复杂逻辑关联，但这正是DTO所不能办到的。
为了解决这个问题，我们可以在服务端添加一个业务逻辑表现，即BO(Business Object)。在这种情况下，MO将不会直接转化为DTO，而是转化为BO。在所有业务处理完毕并需要将数据发送给客户的时候，BO转化为DTO以进行传输。
而在客户端，我们同样可以引入一层新的更适合于页面逻辑的数据表现。这种数据表现被称为VM(View Model)，即为了表观展示所定义的模型。有时候，有些类库提供了更为简单的方法，例如YUI和ExJS所提供的Mixin功能。
当然，当添加这些数据表现形式之前，开发人员需要仔细考量添加这些模型所需要的工作量和所带来的效益之间的平衡。
DTO vs DAO：
有些人看到这个标题可能会一愣。是的，两者并没有可比性。但是如果一个人了解了DTO，并知道DAO是Data Access Object的缩写，那么他可能会很自然的认为DAO与DTO类似,是用来表示从DAL所取得的用来表示数据库中的数据类型。
可实际上，DAO则是一种数据库访问逻辑的一种标准模式。也就是说，与其对应的应该是Repository模式等一系列数据访问的常用方法。