一，一些可改进的代码片段
据我平常观察，周围的同事还存在不少类似的代码，举两例进行说明：
这段是操作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/
1657
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
