上一篇：应用程序框架设计之前言
还记得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 Object（DO）。我们也可以把VO，BO和PO看成是DO在不同阶段的不同表示形态。当一个DO从显示层开始穿越整个系统的时候，它的形态和结构就开始变化，从VO转变到BO，最终到PO，但是这个过程不一定是可逆的，这个过程如果反向，从PO->BO->VO，很可能就对应不同的对象了。比如当输入错误的时候，回馈页面可能就需要增加一个错误信息提示。虽然实际使用的时候，我们经常会忽略这种细微的差异性，实际上这个错误信息，只对显示层有意义。
DO的转换规律一般可以总结为如下的几个类型，实际变化则可以是各种类型的组合：
- 属性内容的减少
属性内容的增减在DO不同形态之间的转变时候经常会发生。比如上例中添加用户LoginInfo对象的VO转换到BO的时候，就需要丢弃“重复输入密码”的属性。有些VO对象甚至根本不需要转换成BO。在BO转换成PO的时候同样也会有属性内容减少的情况出现，比如“部门”这类树状层次结构对象，因为运行效率的因素，也许会需要BO中有“下级部门列表”，实际存储到数据库的时候，PO只需要一个“上级部门ID”就可以了。
- 对象内容的填充或者增加
属性内容同样会有可能增加，但是在系统处理DO转换的时候，属性增加可能就意味着需要进行额外的查询和填充，比如我们使用“用户名”和“密码”进行登录的时候，最终系统需要通过数据库查询得到并且存储“用户ID”，以此来保证用户的唯一性。又比如提交的数据存在校验错误，我们可能需要重新刷新该页面，并且增加新属性“ErrorMessage”，以便把它显示在界面上，提醒用户注意。
- 对象的拆分和组合
我们可以看上面最后一个“添加用户”的例子，一个LoginInfo的BO转化为PO的时候被拆分成了2个对象，一个存放基本的用户信息，一个存放对应的Role信息。通常对象拆分的时候，常常需要填充或者补足新对象的内容；而对象合并的时候，常常出现内容减少的情况。
- 对象或者属性类型的变化
出现对象属性类型的变化在VO到BO的转换中比较常见，比如把用户输入的生日转化为一个真正的DateTime类型。
- 属性名称的变化
属性名称在转换过程中会有变化，一般这种情况应该尽可能不要出现，但是在项目重构的时候出现的概率较大。
除了DO不同形态之间的转换规律之外，不同形态内部还有不同的工作要做：
- 校验
“不要相信任何用户的输入”，这是设计程序跟用户进行交互操作时候永远需要遵守的一个原则。也就是所有的外部输入都需要进行正确性的校验。校验器是分为两个层次，一个是属性层次的校验，比如“年龄”只能0到150之间有效。另外一个是对象层次的校验，或者说跨属性层次的校验，比如“年份输入闰年的时候，2月可以有29日”等。
校验并不是一个单纯的问题，几乎所有的业务逻辑校验基本都需要一次完整的贯穿所有层次的调用。代价颇大。这个也是为什么我们在显示层做很多事先校验，而一旦进入业务逻辑层的时候，校验就经常会被“事后校验”代替了，人们会使用抛出异常的方法来代替“事前检查”。
突然想起来有一句闲话要讲。这个分析过程其实在一年前就完成了，那个时候正好沸沸扬扬的SOA满天飞，当把这个DO形态分析完毕之后，回头看SOA发现它并不属于表现层，而是属于业务逻辑层，换句话说它使用的DO必须是BO而不是VO。而所谓的SOA也不过就是分布的业务逻辑层而已。
因为以下的部分要花费较多的时间查找，bigtall怕文章搁久馊了，也怕各位看官等得太久，就分两部分发吧。下篇我们着重分析现net平台和java平台的几个架构在DO形态上的对比，还要谈一个实用的问题，是不是需要对象ID的问题。
---
2009-8-12 更正DO误作DTO的问题。
