基于BeanUtils和Annotation的值copy工具类(转载)

最新推荐文章于 2024-10-23 22:20:33 发布

lgreckey

最新推荐文章于 2024-10-23 22:20:33 发布

阅读量1.7k

点赞数

CC 4.0 BY-SA版权

文章标签：工具 bean string hashmap exception hibernate

本文链接：https://blog.youkuaiyun.com/lgreckey/article/details/1967399

本文探讨了如何改进常见的Java代码片段，减少冗余的getter/setter调用。作者提出，虽然BeanUtils的populate方法可以简化部分操作，但其要求Map类型的源对象，且不适应不同命名习惯。因此，文章建议扩展BeanUtils以适应更多的场景，包括从ResultSet、请求参数到Java Bean的值复制，并强调了这种值复制在各种场景中的普遍性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

关键字
Javabean, beanutils, annotation, introspection, SQL, ORM

一，一些可改进的代码片段
据我平常观察，周围的同事还存在不少类似的代码，举两例进行说明：
这段是操作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的这个工具包，都会留意到它的这两个实用功能：

BeanUtils.populate(dest, src)
此方法可以将src对象中的属性值，逐一对应地填充到做为dest参数的JavaBean中，
但有两点限制：
1,，src对象一定是Map类型；就像前面的例子中提到的一样
2,，src对象中的key值，一定是和JavaBean提供的setter方法保持统一的命名规范，因为populate的内部实现本身就是基于introspection的．
BeanUtils.copyProperties(dest, src)
这个就更直接了．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即可．
内部实现代码如下：
1. public static void setValues(Object dest, Object src) throws Exception {
2. Map propAliasMap = getPropertyAliasMap(dest, "alias_as_key");
3. if (src instanceof HttpServletRequest) {
4. BeanUtils.populate(dest, mapToMap(((HttpServletRequest) src)
5. .getParameterMap(), propAliasMap));
6. } else if (src instanceof ResultSet) {
7. BeanUtils.populate(dest, resultSetToMap((ResultSet) src,
8. propAliasMap));
9. } else if (src instanceof String) {
10. BeanUtils.populate(dest, keyValueToMap((String) src, propAliasMap));
11. } else if (src instanceof Map) {
12. BeanUtils.populate(dest, mapToMap((Map) src, propAliasMap));
13. } else {
14. BeanUtils.populate(dest, beanToMap(src, propAliasMap));
15. }
16. }
至于将特定对象转成Map的方法，一般人都可以想当然的知道了，不必螯述．
如果使用过Spring的JdbcTemplate，它其中的queryForList(sql)默认就提供了一个RowMapper实现，每行ResultSet就会自动转成Map．
但如果需要自定义RowMapper转换特定类型的话，就正好可以搭配本文的工具包使用，直接对每行rs对象进行值copy到Bean对象．本文最后会有代码示例说明这点．
通过这样通过的处理后，我们可以用同一行代码，完成几乎常用的值copy操作，比如：
1. 　　ModelValueUtils.setValues(Object dest, Object src);
2. 　 // 这个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．
这里用我工具包里的实现代码做示例说明，看代码可以一目了然！
再帖一段前述的代码，以做对比：
1. CustBean bean = new CustBean();
2. bean.setCustId(request.getParameter("CUST_ID"))
3. bean.setCustName(request.getParameter("CUST_NAME"))
4. ...
6. //CustBean的代码一般会是：
7. public class CustBean {
8. private String custId;
9. private String custName;
10. ....
11. // getter & setter
12. }
这种情况下，页面参数名和Bean的property并不匹配，我们需要定义映身关系．就像Hibernate的mapping文件一样．
将CustBean的代码稍做修改．
1. public class CustBean {
3. @ModelPropertyAlias("CUST_ID")
4. private String custId;
6. @ModelPropertyAlias("CUST_NAME")
7. private String custName;
8. ....
9. // getter & setter
10. }
完成这样的标注定义后，我们再用回上面的 ModelValueUtils.setValues()，就完全搞定了！
可以看到上一节所帖的setValues()的实现代码片段，其中有一行：
1. 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处理方式，代码如下：
1. public interface PropertyAliasMapper {
2. public HashMap<String, String> getPropertyAliasMap(Object obj, String key) throws Exception;
3. }
使用它，可以自已对目标Bean的所有property进行遍历，批量处理映射关系，返回一个自定义的别名映射表即可．
当然，这时候已经不是基于Annotation进行处理了，而你往往得用Reflection机制自已搞定．如下面的代码：
1. class ModelPropertyAliasMapper implements PropertyAliasMapper {
2. public HashMap<String, String> getPropertyAliasMap(Object obj, String key) throws Exception {
3. HashMap<String, String> m = new HashMap<String, String>();
4. Field[] fields = obj.getClass().getDeclaredFields();
5. String alias;
6. for(Field field : fields) {
7. alias = field.getName().toUpperCase()
8. if (key.equals("name_as_key")) {
9. m.put(field.getName(), alias);
10. } else {
11. m.put(alias, field.getName());
12. }
13. }
14. return m;
15. }
16. }
这个ModelPropertyAliasMapper的实现，就是将所有property名称，统一映射一个＂全大写＂的别名．这对于从Oracle数据表中返回的ResultSet就可以直接进行值copy了．
不过，你的字段名组成字母，还是得和property一致．如果你非得加上下划线什么的，就得看看你的编程功力了，能否进行统一分词处理，然后在中间加上下划线了

五，总结一下使用上的代码
1, 如果你在Servlet/Jsp中直接给Bean赋值时，推荐只用这一句：
1. ModelValueUtils.setValues(someBean, request);
2, 如果你在DAO中直接给Bean赋值时，推荐只用这一句：
1. ModelValueUtils.setValues(someBean, rs);
3, 如果你在用Spring的JdbcTemplate，在需要返回特定类型的对象List，不妨看下这个RowMapper实现：
1. class ModelRowMapper implements RowMapper {
2. private Class cls;
3. public ModelRowMapper(Class cls) {
4. this.cls = cls;
5. }
6. public Object mapRow(ResultSet rs, int index) throws SQLException {
7. Object model = null;
8. try {
9. model = this.cls.newInstance();
10. ModelValueUtils.setValues(model, rs);
11. } catch(Exception e) {
12. logger.error(e, e);
13. }
14. return model;
15. }
16. }
17. ...
18. ...
19. // 调用时，只需这样一行搞定!　而且，这个RowMapper实现是通用的，类型无关的．
20. return this.jdbcTemplate.query(sql, getModelRowMapper(cls));
21. ...
4, 如果你也和我一样在用DWR/Buffalo，解析前端页面的大量Key=Value参数时，推荐用下面的代码：
1. Map params = ModelValueUtils.keyValueToMap(keyValueStr);
至于key=value的生成，前面已经讲了．
或者，你有自已定义好的Bean来做为参数对象，那直接用它：
1. 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/