还记得97年左右开始的胖客户机和瘦客户机之争吗？之后又是CS和BS之争，然后又是两层和多层之争...，十年之后的今天我们再回过头看这些争论，一切似乎看起来都那么理所应当：程序怎么能不分层啊？可是再想一下，原来我们用了整整十年的时间才达成了一个程序架构要多层的共识（效率多低啊）！
要分层，当然基本就是三层了，其实多层的基础也是三层：界面层、业务逻辑层、存储层。多层只不过在三层的基础上把每一层或多或少再拆分出一些来而已，总的来说没有什么大的变化。本系列文章中讨论都以三层为基本概念。
本文着重讨论的不是如何分层和层的定义，而是在分层情况下，讨论层与层之间的数据传递问题。现在的程序很少仔细地去分析层与层之间的数据传递问题，通常都是一个对象从界面生成开始一路穿过，直接保存到数据库（最显著的标志当然就是xxxID了）。这样的做法对程序伤害很大。
首先我们从一个简单的例子开始：应用程序的添加用户功能。界面很简单，如下：
添加用户登录名
密码
添加用户
要为这个界面设计数据结构通常也很简单，class LoginInfo{ public String name; public String password; } 就好了，然后我们在form提交的时候new一个并且填充好LoginInfo结构，就save(loginInfo)到数据库里边了，最常的做法还会加入一个int loginInfoID字段。我们把这种类似LoginInfo可以直接存储到数据库中的数据结构命名为Persistence Object，简称PO。嗯，看起来从头到脚用一个数据结构并没有什么问题啊！
问题会来的，bigtall来改变一下需求，通常我们需要给用户密码输入两次，所以界面修改如下：
添加用户登录名
密码
重复输入
添加用户
这样，form提交到服务器的数据结构就应该是这样：class LoginInfo2{ public String name; public String password; public String password2; }，然后服务器做的第一件事情就是比较password和password2是否相等，然后new一个LoginInfo结构，把name和 password填充到里边，然后保存到数据库。我们同时把LoginInfo结构修改成这样class LoginInfo{ public int loginInfoID; public String name; public String password; } 。
大家可以看到，随着需求的变化，原来的“PO直通车”演化成了两个结构，我们把LoginInfo2类似的界面层和其它层沟通的数据结构叫做View Object，简称VO。是不是这样就够了？当然不是，我们再来修改一下需求，给系统加入权限功能，所以这个添加用户实际上应该修改成这样：
添加用户登录名
密码
重复输入
管理员 部门经理 普通员工
添加用户
我们需要继续做一些改进（或者叫做“重构”吧），首先修改VO，同时我们把命名也规范一下：
class LoginInfoVO{public String name; public String password; public String password2; public String[] roles;}，
然后把以前的LoginInfo拆分成三个类：
class LoginInfoBO{public String name; public String password; public RoleInfo[] roles;}
class LoginInfoPO{public int loginInfoID; public String name; public String password;}
class RoleInfoPO{public int loginInfoID; public String role;}。
至此，我们顺利地引出了三个概念：View Object（VO）、Business Object（BO）、Persistence Object（PO）。他们分别是三层结构的显示层、业务逻辑层和存储层内部使用的数据结构，它们还有一个统称，叫做数据传输对象Data Transfer Object（DTO）。我们也可以把VO，BO和PO看成是DTO在不同阶段的不同表示形态。当一个DTO从显示层开始穿越整个系统的时候，它的形态和结构就开始变化，从VO转变到BO，最终到PO，但是这个过程不一定是可逆的，这个过程如果反向，从PO->BO->VO，很可能就对应不同的对象了。比如当输入错误的时候，回馈页面可能就需要增加一个错误信息提示。虽然实际使用的时候，我们经常会忽略这种细微的差异性，实际上这个错误信息，只对显示层有意义。
DTO的转换规律一般可以总结为如下的几个类型，实际变化则可以是各种类型的组合：
* 属性内容的减少
属性内容的增减在DTO不同形态之间的转变时候经常会发生。比如上例中添加用户LoginInfo对象的VO转换到BO的时候，就需要丢弃“重复输入密码”的属性。有些VO对象甚至根本不需要转换成BO。在BO转换成PO的时候同样也会有属性内容减少的情况出现，比如“部门”这类树状层次结构对象，因为运行效率的因素，也许会需要BO中有“下级部门列表”，实际存储到数据库的时候，PO只需要一个“上级部门ID”就可以了。
* 对象内容的填充或者增加
属性内容同样会有可能增加，但是在系统处理DTO转换的时候，属性增加可能就意味着需要进行额外的查询和填充，比如我们使用“用户名”和“密码”进行登录的时候，最终系统需要通过数据库查询得到并且存储“用户ID”，以此来保证用户的唯一性。又比如提交的数据存在校验错误，我们可能需要重新刷新该页面，并且增加新属性“ErrorMessage”，以便把它显示在界面上，提醒用户注意。
* 对象的拆分和组合
我们可以看上面最后一个“添加用户”的例子，一个LoginInfo的BO转化为PO的时候被拆分成了2个对象，一个存放基本的用户信息，一个存放对应的Role信息。通常对象拆分的时候，常常需要填充或者补足新对象的内容；而对象合并的时候，常常出现内容减少的情况。
* 对象或者属性类型的变化
出现对象属性类型的变化在VO到BO的转换中比较常见，比如把用户输入的生日转化为一个真正的DateTime类型。
* 属性名称的变化
属性名称在转换过程中会有变化，一般这种情况应该尽可能不要出现，但是在项目重构的时候出现的概率较大。
除了DTO不同形态之间的转换规律之外，不同形态内部还有不同的工作要做：
* 校验
“不要相信任何用户的输入”，这是设计程序跟用户进行交互操作时候永远需要遵守的一个原则。也就是所有的外部输入都需要进行正确性的校验。校验器是分为两个层次，一个是属性层次的校验，比如“年龄”只能0到150之间有效。另外一个是对象层次的校验，或者说跨属性层次的校验，比如“年份输入闰年的时候，2月可以有29日”等。
校验并不是一个单纯的问题，几乎所有的业务逻辑校验基本都需要一次完整的贯穿所有层次的调用。代价颇大。这个也是为什么我们在显示层做很多事先校验，而一旦进入业务逻辑层的时候，校验就经常会被“事后校验”代替了，人们会使用抛出异常的方法来代替“事前检查”。
突然想起来有一句闲话要讲。这个分析过程其实在一年前就完成了，那个时候正好沸沸扬扬的SOA满天飞，当把这个DTO形态分析完毕之后，回头看 SOA发现它并不属于表现层，而是属于业务逻辑层，换句话说它使用的DTO必须是BO而不是VO。而所谓的SOA也不过就是分布的业务逻辑层而已。
因为以下的部分要花费较多的时间查找，bigtall怕文章搁久馊了，也怕各位看官等得太久，就分两部分发吧。下篇我们着重分析现net平台和java平台的几个架构在DTO形态上的对比，还要谈一个实用的问题，是不是需要对象ID的问题。
看了上篇之后大家的留言，好多人觉得DTO分这么多形态，给这么多名词，可能在实际中没有用处。其实相比.net而言，java在架构上的功力要深厚许多，要谈架构如果避开java不谈的话，就会肤浅许多。这一点上net可能还要许多年才能赶上（如果不加倍努力，恐怕永远就落后于java了）。至于说VO、BO、PO没有人分那么仔细，恐怕只是大家自己没有意识到自己在使用吧。正好下篇要对流行的架构进行分析，bigtall就斗胆show一下分析结果了。
针对在DTO的形态转换问题，bigtall选择了几个流行的架构进行了分析，主要就是想要看看他们是怎么做的，这几个架构分别是Petshop 4.0, Struts, Tapestry, Spring MVC。
首先我们看Petshop4，项目中包含22个子项目，我们按照三层架构的层次分类对这些子项目归类：
显示层：WEB CacheDependencyFactory ICacheDependency TableCacheDependency
业务层：Model BLL IBLLStrategy IMessaging MessagingFactory MSMQMessaging OrderProcessor
存储层： DALFactory IDAL DBUtility OracleDAL SQLServerDAL
权限相关的独立部分：SQLProfileDAL ProfileDALFactory OracleProfileDAL IProfileDAL Membership Profile
大家注意业务层的Model，里边定义了项目中使用到的所有数据对象，典型的BO。因为asp.net的组件化设计思想，导致没有明确的VO概念（被分散在诸如textBox1.Text中了）。但是我们看WEB项目中的AddressForm自定义控件代码：
public partial class AddressForm : System.Web.UI.UserControl {
public AddressInfo Address {
get { ....
string firstName = WebUtility.InputText(txtFirstName.Text, 50);
......
return new AddressInfo(firstName, lastName, address1, address2, city, state, zip, country, phone, email);
}
set {
if(value != null) {
...
if(!string.IsNullOrEmpty(value.FirstName))
txtFirstName.Text = value.FirstName;
...
}
}
}
}
分明就是一个典型的VO到BO之间相互映射的代码。同样我们看同一project下的CheckOut.aspx.cs也存在类似的转换代码：从 WEB界面控件中提取数据，构建OrderInfo，最终传入SQLServerDAL或者OracleDAL的Order类中，大家可以看到如下的代码：
public void Insert(OrderInfo order) {...
orderParms[0].Value = order.UserId;
...
orderParms[19].Value = order.AuthorizationNumber.Value;
...
}
这个同样是一个典型的BO到PO的转换过程，只不过我们用类似Hashtable的结构代替了自定义的PO对象而已。
参考文献：Microsoft .NET Pet Shop 4 架构与技术分析
接下来我们来看Struts。所有的WEB提交数据被放置到所谓的ActionForm对象中，很多人为了方便，直接自定义了一个类似Hashtable的结构来做通用的 ActionForm了。这个ActionForm就是我们所说的VO。然后ActionForm传递给Action进行处理，一般Action都会把 ActionForm内容作一次校验，然后构建BO，传递到Service层进行处理，Service层进行处理之后，调用DAO对象存储。因为java 程序基本都使用了hibernate或者ibatis等模块，所以BO到PO的转换被封装掉了。
这里很多人使用struts或者其他java框架的时候，经常在Action中添加了过多的业务逻辑代码，把原本属于界面层后端的Action做成了业务层的东西，然后图方便对Service层代码只是做一个简单的转发调用，类似boolean XXService(XXBO bo) { return dao.save(bo); }，实在是大错特错了。
说明：bigtall并不认同参考文献中认为的Action属于业务逻辑层。我认为业务逻辑层判断的一个标准是不加修改或者加一个简单的wrap，就可以暴露服务作为SOA。Action显然不满足这样的要求。退一步如果非要说Action属于业务逻辑层，那也只能是一个专门针对struts的 Service封装接口，不合适包含大量的业务逻辑代码。
Struts返回数据到界面层的方法是通过把BO填入到一个Hashtable结构，由界面jsp直接使用其值，就跟asp用法一样。
参考文献：Struts，MVC 的一种开放源码实现
Tapestry框架是一个和asp.net采用了相似设计思想的组件化的web框架。一个web请求提交到服务器的时候，tapestry把请求中的内容填入到页面对应的BasePage派生类对象的属性中，这是一个自动的VO填充过程（类似asp.net中把用户输入的内容填充到对应的TextBox对象的Text属性中）。然后这个BasePage派生类对象把自己的属性最终填充成一个 BO，传递到Service层，Service层调用DAO对象通过Hibernate或者ibatis存储到数据库中。
返回数据到界面层使用ognl表达式，基本原理类似把BO或者VO填入Hashtable结构，然后酌情用ognl表达式选取。比asp/jsp用法要利索一些，因为是组件化，所以很整齐。
参考文献：了解 Tapestry，第 1 部分，了解 Tapestry，第 2 部分
Spring作为No.1的AOP框架，灵活性和可扩展性是它最大的优点。在Spring MVC框架中，web请求通过参数HttpServletRequest（类似一个Hashtable结构）存放所有的用户请求数据，传递给 Controller处理。如果Controller是从SimpleFormController派生而来，则可以在jsp中使用bind机制自动把提交数据填充到一个指定的对象中（也就是VO了），否则就要手工从HttpServletRequest中获取。在Controller中可以把数据传递给 Service层处理了。Service层的处理和其它java框架相同。
返回数据到界面层可以使用很多种方法，看使用不同的ViewResolver而定，可以用jsp，也可以用freemarker脚本或者velocity脚本，也可以自己定义一种新型的界面层描述。
参考文献：一步一步开发Spring Framework MVC 应用程序
从以上简单几个架构的分析，我们可以明显看出VO/BO/PO的相互转换过程。但是都有一个特点，就是对VO转BO有明确的处理和包装，但是对BO转VO忽略掉了，直接使用暴露BO对象，使用ognl或者其他技术直接取值。asp.net的WebForm相对复杂一点，但是也同样避开了VO的问题，但是赋值放到了类代码里边，灵活性相对少了一些。而BO转PO的问题，都倾向于用类似ORM的模块来处理。
DTO形态之间的转换讲了一大半，但是一个很实际的问题需要我们来面对，就是数据库ID的暴露问题。根据我们的理论，ID实际是属于PO的东西（以下简称POID），其实VO和BO中并不需要这个POID，另外就是暴露这个POID之后会存在很多的隐患，一旦程序检查不严格，很容易被人假造一个请求去修改不应该的数据。但是我们真的可以抛弃POID不用吗？bigtall同样用一个例子来说明。
bigtall依旧使用上篇的LoginInfo的例子，不过这次的场景是查询特定的LoginInfo并修改之。这个场景包含了如下的几个过程：
1. 输入查询条件LoginInfoQuery到服务层，并返回LoginInfoBO[]对象数组。
2. 展示LoginInfoBO的数据在界面层，并等待修改
3. 保存界面层提交的修改之后的LoginInfoBO到数据库
这里就暴露了一个问题，如何让系统了解第3步和第2步的LoginInfoBO就是同一个对象？同样问题也存在BO和PO的转换中，如何把特定的 BO转化为特定的PO？这个也就是我们现在为什么摆脱不掉这个POID的根本原因了。一句话，没有POID，我们无法解决对象映射的问题。
真的我们只能通过POID来实现对象映射吗？不是！我们有很多方法可以解决这个问题，只是不如直接使用POID来的方便。比如我们是不是可以用一个 Hashtable来保存VP、BO和PO映射关系？当然可以，但是我想我们可以用更好的方法，因为这个问题归根到底就是对象唯一标识（以下简称OID）的问题。
要解决这个问题，我们需要两个条件：一是对象有一个唯一的标识序号OID，二是保存VO和BO、BO和PO对象之间的唯一标识映射关系。直接使用 POID可以很容易满足这两个条件，但是带来了极大的程序风险，一旦界面层保存的POID被非法修改的话，程序对这方面的防范很困难，而且很多程序根本就是完全假设界面层POID是可靠的。但是如果程序应用在金融、财务等领域，操作人员就会极有可能有动机去修改这个界面层（尤其是浏览器中）的POID。而且从一般情况下他们会很容易推卸责任（程序bug嘛！要赔偿也是软件开发商赔偿）。所以，可靠的做法就是避免把POID当作通用的OID，而是给每一个对象分配一个OID，同时保证OID之间的简单映射关系。
bigtall给出的OID设计是这样的：所有的DTO对象都继承接口IIdentitable，接口IIdentitable有唯一的属性 OID，对象构造的时候，由ClassFactory或者自身的构造函数自动给OID赋值，赋值的算法是这样的：使用session id的简单转换作为key，把POID加入一个校验位（记得身份证号码最后的X吗？）之后的新POID用DES算法加密，这个加密之后的结果就作为BO的 OID，如果需要，同样的步骤可以用作BOID到VOID的转换中。用这个算法可以保证不同用户的不同次登录的session id是完全不一样的，所以无法通过简单复制获得OID。其次要配合检查程序，避免用户查询到不属于自己业务范畴的数据，并尽可能对操作对象进行权限检查。
至此，bigtall把DTO的形态变化讲完了，其实还有另外一个重要的概念，DTO的设计。这个设计重要吗？答案是很重要！请看bigtall的“应用程序框架设计之三：数据传递对象的类型和设计”。