应用程序框架设计之二:分层和层间数据传递(下)看 了上篇之后大家的留言,好多人觉得DO分这么多形态,给这么多名词,可能在实际中没有用处。其实相比.net而言,java在架构上的功力要深厚许多,要 谈架构如果避开java不谈的话,就会肤浅许多。这一点上net可能还要许多年才能赶上(如果不加倍努力,恐怕永远就落后于java了)。至于说VO、 BO、PO没有人分那么仔细,恐怕只是大家自己没有意识到自己在使用吧。正好下篇要对流行的架构进行分析,bigtall就斗胆show一下分析结果了。 针对在DO的形态转换问题,bigtall选择了几个流行的架构进行了分析,主要就是想要看看他们是怎么做的,这几个架构分别是Petshop 4.0, Struts, Tapestry, Spring MVC。 首先我们看Petshop4,项目中包含22个子项目,我们按照三层架构的层次分类对这些子项目归类:
大家注意业务层的Model,里边定义了项目中使用到的所有数据对象,典型的BO。因为asp.net的组件化设计思想,导致没有明确的VO概念(被分散在诸如textBox1.Text中了)。但是我们看WEB项目中的AddressForm自定义控件代码:
分 明就是一个典型的VO到BO之间相互映射的代码。同样我们看同一project下的CheckOut.aspx.cs也存在类似的转换代码:从WEB界面 控件中提取数据,构建OrderInfo,最终传入SQLServerDAL或者OracleDAL的Order类中,大家可以看到如下的代码:
这个同样是一个典型的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返回数据到界面层的方法是通过把BO填入到一个Hashtable结构,由界面jsp直接使用其值,就跟asp用法一样。
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并修改之。这个场景包含了如下的几个过程:
这 里就暴露了一个问题,如何让系统了解第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的“应用程序框架设计之三:数据传递对象的类型和设计”。 |
|