一,一些可改进的代码片段
据我平常观察,周围的同事还存在不少类似的代码,举两例进行说明:
这段是操作ResultSet的
- CustBean bean = new CustBean () ;
- bean . setCustId ( rs . getString ( " CUST_ID " ))
- bean . setCustName ( rs . getString ( " CUST_NAME " ))
- ....
- // more similar code
- ...
这段是Servlet或其它业务类中的
- CustBean bean = new CustBean () ;
- bean . setCustId ( request . getParameter ( " CUST_ID " ))
- bean . setCustName ( request . getParameter ( " CUST_NAME " ))
- ....
依次类推,类似的getter/setter随处可见,以至代码相当冗余,还白白耗费键盘功夫.
当然,以上的代码如果在hibernate或其它ORM框架的支撑下,是不会出现的.
所以,你如果从一开始就掉在这些框架温柔的陷井里,也许还会难以理解这种写法的存在.
拿第二段来说,如果页面传入参数的名称和Bean中的property一致的话,其实就可以用commons beanutils工具包来简化:
- BeanUtils . populate ( bean , request . getParameterMap ())
那更进一步,如果常用对象都能用值copy的方式送入到指定bean中,代码量将大大减少;
可遗憾的是,BeanUtils.populate()方法,源对象参数只能是Map类型,
况且,对于数据库表字段或者页面参数命名,有人喜欢大写加个下划线,有人喜欢小写加个下划线,而我个人则喜欢直接用Java类命名方式:首字母大写来搞定.
所以,想要进行省事的值copy运算,得对beanutils进行扩展,以适应不同的场景,必竟人的习惯是一样很可怕的东西,相当顽固,一旦养成,很难改变.
其实,在Java中从某种内部对象向bean进行的值copy场景,出现的机率是相当高的.除非你完全摒弃MVC的精神,另搞一套新鲜玩法.
还有些场景,我们得从外部XML直接装载数据到bean ,这些都算是一种值copy的应用,基本可以说无处不在!
二,回头再从beanutils说起
如果曾用过apache commons的这个工具包,都会留意到它的这两个实用功能:
此方法可以将src对象中的属性值,逐一对应地填充到做为dest参数的JavaBean中,
但有两点限制:
1,,src对象一定是Map类型;就像前面的例子中提到的一样
2,,src对象中的key值,一定是和JavaBean提供的setter方法保持统一的命名规范,因为populate的内部实现本身就是基于introspection的.
这个就更直接了.dest和src都是JavaBean,但两者所属类型可以不一样,只要property的setter能对应起来,就能够完成值copy.
在本文的工具案例中,对于copyProperties是不需要的,已经给了替代统一的实现方案.
很显然,以上两个方法都是挺实用的.在不少我们已接触的开源框架中都有用到beanutils,Struts的ActionForm值自动填充就是一例.
但在我个人实用应用中,它们都表现很大的局限性,仍然不够灵活.
最为突出的不便之处在于,beanutils对于src参数对象的要求太过于苛刻了:
1,populate的源参数对象只接收Map类型
2,key值得符合dest bean的命名规范, 才能进行值copy.
三,扩展源值对象的类型支持
在一般J2EE WEB应用开发中,可能出现值copy的地方一般会有两种:
1, 从ResultSet对象中提取数据,送入Bean
2, 从HttpServletRequest对象中提取数据,送入Bean.同前述ActionForm
情况1往往会出现在读取数据库进行业务展现时,而情况2则反之,是从获取从前台提交的数据做业务处理,然后写表.
而我个人还会碰一种情况.
在DWR做辅助开发时,如果需要向一个后台DAO对象传送多个页面参数时,我喜欢用prototype提供的一个方法:
Form.serialize( $(’someForm’) )
这个方法,可以直接将Form上所有表单元素,生成key=value的标准Http GET参数串形式,然后我会将此串直接传入DWR后台业务对象处理.
这样不但省掉了定义多个方法参数的麻烦,也便于参数个数的任意调整,应对需求变化很实用.
那对于这种 key=value的字符串参数,我需要也能直接进行值copy,绑定到bean才行.
当然,除了上面的ResultSet, HttpServletRequest, String三类,beanutils默认支持的Map,普通Bean当然也需要在考虑之中.
这一步的修改,比较简单.我们只要将这几种类型统一转成Map,再用beanutils的populate即可.
内部实现代码如下:
- public static void setValues ( Object dest , Object src ) throws Exception {
- Map propAliasMap = getPropertyAliasMap ( dest , " alias_as_key " ) ;
- if ( src instanceof HttpServletRequest ) {
- BeanUtils . populate ( dest , mapToMap ((( HttpServletRequest ) src )
- . getParameterMap () , propAliasMap )) ;
- } else if ( src instanceof ResultSet ) {
- BeanUtils . populate ( dest , resultSetToMap (( ResultSet ) src ,
- propAliasMap )) ;
- } else if ( src instanceof String ) {
- BeanUtils . populate ( dest , keyValueToMap (( String ) src , propAliasMap )) ;
- } else if ( src instanceof Map ) {
- BeanUtils . populate ( dest , mapToMap (( Map ) src , propAliasMap )) ;
- } else {
- BeanUtils . populate ( dest , beanToMap ( src , propAliasMap )) ;
- }
- }
至于将特定对象转成Map的方法,一般人都可以想当然的知道了,不必螯述.
如果使用过Spring的JdbcTemplate,它其中的queryForList(sql)默认就提供了一个RowMapper实现,每行ResultSet就会自动转成Map.
但如果需要自定义RowMapper转换特定类型的话,就正好可以搭配本文的工具包使用,直接对每行rs对象进行值copy到Bean对象.本文最后会有代码示例说明这点.
通过这样通过的处理后,我们可以用同一行代码,完成几乎常用的值copy操作,比如:
- ModelValueUtils . setValues ( Object dest , Object src ) ;
- // 这个src对象的类型,就比较灵活了
四,解决Key值对Bean的property映射
看完上面一节,你是不是已发现了一些相关的东西.
在解决了对多种源值对象类型的支持后,现在就该来解决每个人的命名习惯问题了.
如前所述.像Hibernate,或者iBatis这类ORM映射框架,它们从数据表里自动获取数据,再绑定到bean时,实际上就完成了一次值copy;
至少它的内部实现,我们无需关注.但可以发现,它们都是采用XML文件,再描述Bean Property和数据表字段的对应关系.
这种做法,在很大程度上已经成为一种习惯.可最终的后果是,它们带来了的XML文件,不是每个人都乐意接受的,甚至有些人一看到XX框架的XML配置就反感.
有所谓重量级和轻量级的判别中,XML配置的大小都成了一个说辞.
google的牛人,自已写了一个guice,实现了几乎和spring一样的IoC容器功能,而无一行XML配置,被人津津乐道,谓之"真正的轻量级诞生了"
呵呵,这个有些扯远了.之所以提到guice,只是想引出 annotation.
说回主题,XML即然麻烦,那最直接,最简单的做法就是Tiger版本的annotation了.
我们需要的就是,在目标Bean的某个property前,加上一行标注,给这个property定义一个可供映射的别名.
这样一来,无论是从ResultSet,还是Request,或者其它类型的源数据Bean中,将值copy到这个目标bean时,名称的对应关系就解决了.每个人的对象属性/表字段命名习惯也就得到最大程度地得到了满足.可以随心所欲.
简单的思路:用annotation来做别名映射,以支持更灵活的值copy.
这里用我工具包里的实现代码做示例说明,看代码可以一目了然!
再帖一段前述的代码,以做对比:
- CustBean bean = new CustBean () ;
- bean . setCustId ( request . getParameter ( " CUST_ID " ))
- bean . setCustName ( request . getParameter ( " CUST_NAME " ))
- ...
- //CustBean的代码一般会是:
- public class CustBean {
- private String custId ;
- private String custName ;
- ....
- // getter & setter
- }
这种情况下,页面参数名和Bean的property并不匹配,我们需要定义映身关系.就像Hibernate的mapping文件一样.
将CustBean的代码稍做修改.
- public class CustBean {
- @ ModelPropertyAlias ( " CUST_ID " )
- private String custId ;
- @ ModelPropertyAlias ( " CUST_NAME " )
- private String custName ;
- ....
- // getter & setter
- }
完成这样的标注定义后,我们再用回上面的 ModelValueUtils.setValues(),就完全搞定了!
可以看到上一节所帖的setValues()的实现代码片段,其中有一行:
- Map propAliasMap = getPropertyAliasMap ( dest , " alias_as_key " ) ;
这行就是先对dest对象进行了Annotation预分析,将定义了别名的属性记录下来,生成一张映射对应表即可.
然后,在将src对象转换成Map时,会使用到这张别名映射表,最终生成的值Map对象,就可以直接为beanutils.populate()方法所用了.
这样我们就成功解决了本节的任务:值copy时的key映射问题.
有两个延伸出来的提示点:
细心的话,你会产生疑问.getPropertyAliasMap()这个方法每次都要去做dest对象的Annotation分析,不是很消耗性能吗?这点我在实际应用中,也有所考虑,并做了相应的AliasMap缓存处理,对于同一类型的对象,不会每次都去分析. 有些情况下,目标bean的property对应的并非是一个完全变异的别名Key,它们可能存在有统一的对应规律.如果还为每个property去标注别名,显然又是重复劳动了.
这里我也预留了一个接口,类似于JdbcTemplate的RowMapper处理方式,代码如下:
- public interface PropertyAliasMapper {
- public HashMap < String , String > getPropertyAliasMap ( Object obj , String key ) throws Exception ;
- }
使用它,可以自已对目标Bean的所有property进行遍历,批量处理映射关系,返回一个自定义的别名映射表即可.
当然,这时候已经不是基于Annotation进行处理了,而你往往得用Reflection机制自已搞定.如下面的代码:
- class ModelPropertyAliasMapper implements PropertyAliasMapper {
- public HashMap < String , String > getPropertyAliasMap ( Object obj , String key ) throws Exception {
- HashMap < String , String > m = new HashMap < String , String > () ;
- Field [] fields = obj . getClass () . getDeclaredFields () ;
- String alias ;
- for ( Field field : fields ) {
- alias = field . getName () . toUpperCase ()
- if ( key . equals ( " name_as_key " )) {
- m . put ( field . getName () , alias ) ;
- } else {
- m . put ( alias , field . getName ()) ;
- }
- }
- return m ;
- }
- }
这个ModelPropertyAliasMapper的实现,就是将所有property名称,统一映射一个"全大写"的别名.这对于从Oracle数据表中返回的ResultSet就可以直接进行值copy了.
不过,你的字段名组成字母,还是得和property一致.如果你非得加上下划线什么的,就得看看你的编程功力了,能否进行统一分词处理,然后在中间加上下划线了
五,总结一下使用上的代码
1, 如果你在Servlet/Jsp中直接给Bean赋值时,推荐只用这一句:
- ModelValueUtils . setValues ( someBean , request ) ;
2, 如果你在DAO中直接给Bean赋值时,推荐只用这一句:
- ModelValueUtils . setValues ( someBean , rs ) ;
3, 如果你在用Spring的JdbcTemplate,在需要返回特定类型的对象List,不妨看下这个RowMapper实现:
- class ModelRowMapper implements RowMapper {
- private Class cls ;
- public ModelRowMapper ( Class cls ) {
- this . cls = cls ;
- }
- public Object mapRow ( ResultSet rs , int index ) throws SQLException {
- Object model = null ;
- try {
- model = this . cls . newInstance () ;
- ModelValueUtils . setValues ( model , rs ) ;
- } catch ( Exception e ) {
- logger . error ( e , e ) ;
- }
- return model ;
- }
- }
- ...
- ...
- // 调用时,只需这样一行搞定! 而且,这个RowMapper实现是通用的,类型无关的.
- return this . jdbcTemplate . query ( sql , getModelRowMapper ( cls )) ;
- ...
4, 如果你也和我一样在用DWR/Buffalo,解析前端页面的大量Key=Value参数时,推荐用下面的代码:
- Map params = ModelValueUtils . keyValueToMap ( keyValueStr ) ;
至于key=value的生成,前面已经讲了.
或者,你有自已定义好的Bean来做为参数对象,那直接用它:
- ModelValueUtils . setValue ( someBean , keyValueStr ) ;
六,可以待续的部分
本文只讲了关于Bean值copy的辅助类 ModelValueUtils.其实它还有一个扩展类: ModelToSQLUtils,这个工具类从字面上你应该可以猜出它的功能.
ModelToSQLUtils就是基于已经被赋值的bean,生成一些常用的SQL语句,当然它仍然得依赖Annatation机制来标注类似于"表名"或"主键字段名"这样的特征描述.
我后面再单独写一篇来简单介绍一下.它主要就是基于ModelValueUtils来实现的,相对而言就更加简单了.
七,此工具包的开源Repository
开源小工具 J2EE MVC开发辅助包
应用场景:BEAN操作辅助
项目地址:http://code.google.com/p/cokemi-utils-mvc/