应用程序框架设计之二：分层和层间数据传递（下）
看了上篇之后大家的留言，好多人觉得DO分这么多形态，给这么多名词，可能在实际中没有用处。其实相比.net而言，java在架构上的功力要深厚许多，要谈架构如果避开java不谈的话，就会肤浅许多。这一点上net可能还要许多年才能赶上（如果不加倍努力，恐怕永远就落后于java了）。至于说VO、BO、PO没有人分那么仔细，恐怕只是大家自己没有意识到自己在使用吧。正好下篇要对流行的架构进行分析，bigtall就斗胆show一下分析结果了。
针对在DO的形态转换问题，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对象而已。
接下来我们来看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用法要利索一些，因为是组件化，所以很整齐。
Spring作为No.1的AOP框架，灵活性和可扩展性是它最大的优点。在Spring MVC框架中，web请求通过参数HttpServletRequest（类似一个Hashtable结构）存放所有的用户请求数据，传递给Controller处理。如果Controller是从SimpleFormController派生而来，则可以在jsp中使用bind机制自动把提交数据填充到一个指定的对象中（也就是VO了），否则就要手工从HttpServletRequest中获取。在Controller中可以把数据传递给Service层处理了。Service层的处理和其它java框架相同。
返回数据到界面层可以使用很多种方法，看使用不同的ViewResolver而定，可以用jsp，也可以用freemarker脚本或者velocity脚本，也可以自己定义一种新型的界面层描述。
从以上简单几个架构的分析，我们可以明显看出VO/BO/PO的相互转换过程。但是都有一个特点，就是对VO转BO有明确的处理和包装，但是对BO转VO忽略掉了，直接使用暴露BO对象，使用ognl或者其他技术直接取值。asp.net的WebForm相对复杂一点，但是也同样避开了VO的问题，但是赋值放到了类代码里边，灵活性相对少了一些。而BO转PO的问题，都倾向于用类似ORM的模块来处理。
DO形态之间的转换讲了一大半，但是一个很实际的问题需要我们来面对，就是数据库ID的暴露问题。根据我们的理论，ID实际是属于PO的东西（以下简称POID），其实VO和BO中并不需要这个POID，另外就是暴露这个POID之后会存在很多的隐患，一旦程序检查不严格，很容易被人假造一个请求去修改不应该的数据。但是我们真的可以抛弃POID不用吗？bigtall同样用一个例子来说明。
bigtall依旧使用上篇的LoginInfo的例子，不过这次的场景是查询特定的LoginInfo并修改之。这个场景包含了如下的几个过程：
- 输入查询条件LoginInfoQuery到服务层，并返回LoginInfoBO[]对象数组。
- 展示LoginInfoBO的数据在界面层，并等待修改
- 保存界面层提交的修改之后的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设计是这样的：所有的DO对象都继承接口IIdentitable，接口IIdentitable有唯一的属性OID，对象构造的时候，由ClassFactory或者自身的构造函数自动给OID赋值，赋值的算法是这样的：使用session id的简单转换作为key，把POID加入一个校验位（记得身份证号码最后的X吗？）之后的新POID用DES算法加密，这个加密之后的结果就作为BO的OID，如果需要，同样的步骤可以用作BOID到VOID的转换中。用这个算法可以保证不同用户的不同次登录的session id是完全不一样的，所以无法通过简单复制获得OID。其次要配合检查程序，避免用户查询到不属于自己业务范畴的数据，并尽可能对操作对象进行权限检查。
至此，bigtall把DO的形态变化讲完了，其实还有另外一个重要的概念，DO的设计。这个设计重要吗？答案是很重要！请看bigtall的“应用程序框架设计之三：数据传递对象的类型和设计”。
---
2009-8-12 更正DO误作DTO的问题。
公众号：老翅寒暑
