应用程序框架设计之二:分层和层间数据传递(下)

上一篇:应用程序框架设计之二:分层和层间数据传递(上)

看了上篇之后大家的留言,好多人觉得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对象而已。

参考文献: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的模块来处理。

DO形态之间的转换讲了一大半,但是一个很实际的问题需要我们来面对,就是数据库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设计是这样的:所有的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的问题。

posted on 2007-12-12 10:22  老翅寒暑  阅读(7175)  评论(27编辑  收藏  举报

导航