BlogJava-nighty-随笔分类-Java

扩展commons dbutils的JavaBean转换方式

寒武纪 — Tue, 26 Apr 2011 08:41:00 GMT

引言：最近又用到dbutils，之前一直用Map映射的方式取出select的结果再手工做转换。有写过一篇文章说MapHandler方式的一个缺陷：关于commons dbutils组件的一个小缺陷分析，用这种方式，在项目不大的情况下，写一些Map到JavaBean的转换代码工作量不大，但是在数据库表过多并且表中的字段过多的情况下，这种重复的setter感觉有点烦。于是又重新思考了BeanHandler和BeanListHandler的情况，dbutils底层映射用的反射，性能上肯定有损失，不过在大多数项目规模不是很大的情况下，这点损失可以忽略，带来的代码减少却是比较可观。
问题在哪里？先看一段官方的示例代码：

QueryRunner run = new QueryRunner(dataSource);

// Use the BeanHandler implementation to convert the first
// ResultSet row into a Person JavaBean.
ResultSetHandler<Person> h = new BeanHandler<Person>(Person.class);

// Execute the SQL statement with one replacement parameter and
// return the results in a new Person object generated by the BeanHandler.
Person p = run.query(
"SELECT * FROM Person WHERE name=?", h, "John Doe");

这里有个地方有约束，就是要求示例中的JavaBean类Person中的字段定义要和数据库的字段定义一致。Java的命名习惯一般是骆峰写法，例如userId，那么数据库中就必须定义为userId，而问题在于：有时候我们需要数据库中字段的定义格式与JavaBean的命名不一样，比如数据库定义为：user_id，而JavaBean则定义为userId
看源代码可能有点费时间，在官方的example页面的最下面果然有一段关于自定义BeanProcessor的指引。摘录出来：

      BasicRowProcessor uses a BeanProcessor to convert ResultSet columns into JavaBean properties. You can subclass and override processing steps to handle datatype mapping specific to your application. The provided implementation delegates datatype conversion to the JDBC driver.
      BeanProcessor maps columns to bean properties as documented in the BeanProcessor.toBean() javadoc. Column names must match the bean's property names case insensitively. For example, the firstname column would be stored in the bean by calling its setFirstName() method. However, many database column names include characters that either can't be used or are not typically used in Java method names. You can do one of the following to map these columns to bean properties:
      1. Alias the column names in the SQL so they match the Java names: select social_sec# as socialSecurityNumber from person
      2. Subclass BeanProcessor and override the mapColumnsToProperties() method to strip out the offending characters.

      大概意思就是提供二种方式：一种就是最直接的，用as关键字把colName重命名，另一种方式就是继承BeanProcessor类，重写mapColumnsToProperties()方法。
      那当然是第二种方式更加具有代表性。尝试了一下。代码如下：

1public class CustomBeanProcessor extends BeanProcessor {
2
3    @Override
4    protected int[] mapColumnsToProperties(ResultSetMetaData rsmd,
5            PropertyDescriptor[] props) throws SQLException {
6        int cols = rsmd.getColumnCount();
7        int columnToProperty[] = new int[cols + 1];
8        Arrays.fill(columnToProperty, PROPERTY_NOT_FOUND);
9
10        for (int col = 1; col <= cols; col++) {
11            String columnName = rsmd.getColumnLabel(col);
12            if (null == columnName || 0 == columnName.length()) {
13              columnName = rsmd.getColumnName(col);
14            }
15            columnName = colNameConvent(columnName); // 在这里进行数据库表columnName的特殊处理
16            for (int i = 0; i < props.length; i++) {
17
18                if (columnName.equalsIgnoreCase(props[i].getName())) {
19                    columnToProperty[col] = i;
20                    break;
21                }
22            }
23        }
24        return columnToProperty;
25    }
26
27    /**
28     * 数据库列名重新约定
29     * @param columnName
30     * @return
31     */
32    private String colNameConvent(String columnName) {
33        String[] strs = columnName.split("_");
34        String conventName = "";
35        for (int i = 0; i < strs.length; i++) {
36            conventName += StringUtils.capitalize(strs[i]);
37        }
38        StringUtils.uncapitalize(conventName);
39        return conventName;
40    }
41}

注意mapColumnsToProperties方法的逻辑是从父类的方法中直接复制出来的，然后在第15行那里变了个戏法，这里的columnName就是从数据库中读出来的，自定义一个private方法用于转换命名，这里你就可以添加自己的命名约束。例如上面就是把 user_id 转化为Java的骆峰写法：userId
再深入一层思考，你可以在这里进行更多扩展，以便让自己可以选择不同的命名转换方式。定义了这个Processor之后，下面看看如何调用：

Connection conn = ConnectionManager.getInstance().getConnection();
QueryRunner qr = new QueryRunner();
CustomBeanProcessor convert = new CustomBeanProcessor();
RowProcessor rp = new BasicRowProcessor(convert);
BeanHandler<User> bh = new BeanHandler<User>(User.class, rp);
User u = qr.query(conn, sql, bh, params);
DbUtils.close(conn);

是不是非常灵活？如果是想返回List结果的，就把BeanHandler替换成BeanListHander类，还可以再进一步封装这些操作，抽象到公共模块中去，让外部直接传入sql语句和Class就能直接返回想要的结果，当然你得增加泛型的定义。同样举一个封装的例子：

1protected <T> List<T> selectBeanList(Connection conn, String sql, Class<T> type,
2            Object[] params) throws Exception {
3        log.debug("select sql:[" + sql + "]");
4        QueryRunner qr = new QueryRunner();
5        CustomBeanProcessor convert = new CustomBeanProcessor();
6        RowProcessor rp = new BasicRowProcessor(convert);
7        ResultSetHandler<List<T>> bh = new BeanListHandler<T>(type, rp);
8        List<T> list = qr.query(conn, sql, bh, params);
9        return list;
10    }

        至于为什么扩展这个方法就可以实现这个逻辑就得去跟源代码看它的内部实现，用了一些JavaBean的处理和反映的技巧来做的。具体就不说。
        总结：commons组件都设计得非常好，可扩展性和实用性都非常高。虽然上面举例实现了转换逻辑的替换，但是仍然需要开发人员在设计数据库的时候和写JavaBean时都要严格做好规范，避免产生不必要的问题。这方面Ruby On Rails就直接内部实现，动态语言的优点特别能体现，同时强制你在设计时必须用这种方式，典型的约定优于配置原则。当然，在dbutils里你愿意二种字段名都一样也无可厚非。
       缺点：BeanProcessor是不支持关联查询的，所以上面的方式也只能局限于单表的转换，这点就不如myBatis和Hibernate，当然用这二个就引入了一些复杂性，如何权衡需要自己衡量，哪个用得好都一样。本人就不喜欢myBatis那种把SQL写到XML中的方式，见过太复杂的SQL最终在XML里面变得面目全非，如果是接手别人的代码，是很痛苦的，而且你无法避免只修改XML而不改Java，既然二者都要改，那直接写Java里又有什么区别？简单就是美。格式和注释写好一点同样很容易理解！

寒武纪 2011-04-26 16:41 发表评论

关于commons dbutils组件的一个小缺陷分析

寒武纪 — Sat, 12 Feb 2011 09:33:00 GMT

非常喜欢这种轻量级的JDBC封装，比起Hibernate和iBatis，可以非常自由和灵活地运用和自行二次封装，由于dbutils的BeanHandler转换方式采取了反射技术，在性能上肯定有所损失，所以项目中基本上都使用MapHandler方式来转换数据，当然就是自己写的代码多一点，也无所谓。一般的查询、子查询、联合查询、包括视图查询等等都很正常，但是发现一个比较小的问题，就是在使用聚合函数的场所，例如：select user_type, count(*) as count from `user` group by user_type这种类型查询的时候，MapHandler方式不起作用，as列都变成key为空串的K-V对，导致有许多地方使用map.get("")代码的情况出现，这种写法当然是不太好的，容易出问题。
鉴于前面没有时间了解，就都粗略使用了上面那种粗暴的map.get("")来处理，最好的情况是让dbutils组件能自动识别到as类型的列名。于是有空了就专门看了看它的源代码，发现最主要的一段代码如下：

1public Map<String, Object> toMap(ResultSet rs) throws SQLException {
2        Map<String, Object> result = new CaseInsensitiveHashMap();
3        ResultSetMetaData rsmd = rs.getMetaData();
4        int cols = rsmd.getColumnCount();
5
6        for (int i = 1; i <= cols; i++) {
7            result.put(rsmd.getColumnName(i), rs.getObject(i));
8        }
9
10        return result;
11    }

CaseInsensitiveHashMap是dbutils自定义的一个Map，忽略键大小写的K-V字典，但是key使用的是ResultSetMetaData.getColumnName()，我想问题大概出在这里，于是认真翻了翻java的api文档（开发做久了容易遗忘基础），果然，原来getColumnName()是：获取指定列的名称；而as关键字之后，使列名称变成用于显示的意义，这个时候应该使用getColumnLabel()：获取用于打印输出和显示的指定列的建议标题。建议标题通常由 SQL AS 子句来指定。如果未指定 SQL AS，则从 getColumnLabel 返回的值将和 getColumnName 方法返回的值相同。自己手动试验了一下，果然如所料，问题就出在这里。
所以呢，如果想要dbutils在自动转换Map及MapList时能识别聚合函数的列名，那么最好的做法就是重载这种方式，懒一点的，你就干脆修改上面那段代码，让它判断是否使用了as关键字。个人暂时搞不清楚官方为什么没有考虑这一步，有时间再思考一下！

寒武纪 2011-02-12 17:33 发表评论

将Apache Roller部署到MyEclipse上面

寒武纪 — Sun, 22 Nov 2009 13:04:00 GMT

摘要: 都说roller在国外是二次开发博客系统的首选，但是下载源代码之后发现是它是基于netbeans项目结构开发的。平时用习惯了Eclipse，所以想搬到MyEclipse上面，但没有想到居然那么不容易，折腾了整整一天，才最终跑起来。网上的参考信息太少，大概都是那二三篇的转贴，全部结合起来就差不多可以解决，借此总结一下，希望用到的朋友有参考作用！阅读全文

寒武纪 2009-11-22 21:04 发表评论

httpClient3.1中文参数GET请求的解决方法

寒武纪 — Wed, 16 Jul 2008 02:31:00 GMT

最近一个程序出了点问题，对于中文参数的GET请求，服务器无法解析出正确的参数。刚好服务器的那端是另一个项目组负责，是异构系统，当初测试的时候也是走流程化，涉及到很多工作上的协调就比较麻烦，测试也不充分，像赶鸭子上架一样就上线了，催说是项目紧急。当然这是话外，不多废话。
httpClient的GetMethod类加入参数的方法是如下：

void	`setQueryString(NameValuePair[] params)` Sets the query string of this HTTP method.
`void`	`setQueryString(String queryString)`

跟踪一下httpClient的GetMethod的源代码，继承自HttpMethodBase，源码如下：

public void setQueryString(String queryString) {
   this.queryString = queryString;
}

public void setQueryString(NameValuePair[] params) {
   LOG.trace("enter HttpMethodBase.setQueryString(NameValuePair[])");
   queryString = EncodingUtil.formUrlEncode(params, "UTF-8");
}

   EncodingUtil是httpClient定义的一个编码工具类，由于默认设置的是UTF-8，所以对于一些系统可能就无法识别。可以在外部这样更改：
method.setQueryString(EncodingUtil.formUrlEncode(pair, "GB2312"));另外，注意请求头也要修改为对应的一致编码方式，method.addRequestHeader("Content-type" , "text/html; charset=GB2312");如果这二个编码不一致，就会引起乱码。
   刚开始的时候尝试过都使用一致的UTF-8，但是发现还是乱码，这应该是服务器的原因。IE默认的就是采用操作系统Windows的中文编码去进行Encoder的，服务器原先基本上都为IE服务的，所以改为GB2312就能正常识别得到。
   另外，上面提到的EncodingUtil这个工具是从apache的另一个组件codec包装而来的，而非SUN的URLEncoder。有兴趣的可以研读一下源代码。

寒武纪 2008-07-16 10:31 发表评论

httpclient3.1使用小结

寒武纪 — Wed, 11 Jun 2008 07:18:00 GMT

Jakarta的httpclient3.1是最新版本，项目中需要用程序模拟浏览器的GET和POST动作。在使用过程中遇到不少问题。
1. 带附件的POST提交
最开始都是使用MultipartPostMethod这个类，现在已经废弃这个类了。API说明：Deprecated. Use MultipartRequestEntity in conjunction with PostMethod instead. 使用PostMethod可以实现的功能，就没有必要再弄一个MultipartPostMethod了。下面是一段最简单的示例：

PostMethod post = new PostMethod();
        NameValuePair[] pairs = new NameValuePair[2];
        pairs[0] = new NameValuePair("para1", "value1");
        pairs[0] = new NameValuePair("para2", "value2");
        post.setRequestBody(pairs);
        HttpClient client = new HttpClient();
        try {
            client.executeMethod(post);
        } catch (HttpException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }

这是针对一般的form形式的提交，而且这个form里面不带附件的。如果带附件，那么这种方法就不起作用，附件上传的参数和普通参数无法一同在服务器获取到。org.apache.commons.httpclient.methods.multipart 这个包就是为处理文件上传这种多形式参数的情况的。最主要的类是Part（代表一种post object），它有二个比较重要的子类：FilePart和StringPart，一个是文件的参数，另一个就是普通的文本参数。它的典型使用方法如下：

String url = "http://localhost:8080/HttpTest/Test";
         PostMethod postMethod = new PostMethod(url);

         StringPart sp = new StringPart("TEXT", "testValue");
         FilePart fp = new FilePart("file", "test.txt", new File("./temp/test.txt"));

         MultipartRequestEntity mrp= new MultipartRequestEntity(new Part[]{sp, fp}, postMethod
                 .getParams());
         postMethod.setRequestEntity(mrp);

         //执行postMethod
         HttpClient httpClient = new HttpClient();
         try {
            httpClient.executeMethod(postMethod);
        } catch (HttpException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }

在第二行PostMethod postMethod = new PostMethod();后面，有人说需要使用postMehtod.setRequestHeader("Content-type", "multipart/form-data"); Content-type的请求类型进行更改。但是我在使用过程没有加上这一句，查了一下httpCleint的默认Content-type是application/octet-stream。应该是没有影响的。对于MIME类型的请求，httpclient建议全用MulitPartRequestEntity进行包装，就是上面的用法。

2. 参数中文的处理问题
httpclient的默认编码都是ISO-8859-1，那肯定就无法支持中文参数了。引用一下这篇文章：http://thinkbase.net/w/main/Wiki?HttpClient+POST+%E7%9A%84+UTF-8+%E7%BC%96%E7%A0%81%E9%97%AE%E9%A2%98 ，按照作者的说法，就可以正常解决中文编码的问题。其中最关键的是修改EncodingUtil这个类的一个方法实现。另外，FilePart和StringPart的构造方法都有一个带编码指定的参数，为了减少问题的出现，建议所有的都带上统一的编码，包括postMethod.getParams()。示例如下：

String url = "http://localhost:8080/HttpTest/Test";
         PostMethod postMethod = new PostMethod(url);

         StringPart sp = new StringPart("TEXT", "testValue", "GB2312");
         FilePart fp = new FilePart("file", "test.txt", new File("./temp/test.txt"), null, "GB2312");

         postMethod.getParams().setContentCharset("GB2312");
         MultipartRequestEntity mrp= new MultipartRequestEntity(new Part[]{sp, fp}, postMethod
                 .getParams());
         postMethod.setRequestEntity(mrp);

         //执行postMethod
         HttpClient httpClient = new HttpClient();
         try {
            httpClient.executeMethod(postMethod);
        } catch (HttpException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }

寒武纪 2008-06-11 15:18 发表评论

关于Java命令行交互方式

寒武纪 — Fri, 23 May 2008 01:41:00 GMT

   普通的程序交互方式有命令行和GUI形式。对于GUI样式，交互的设计可以多种多样，但是Java做命令行交互，似乎存在着一些不足。
   命令行交互是传统的交互方式，如果程序有时候需要在Unix或是Linux等系统上运动时，以这种方式出现的可能性就比较大。命令行包括
   输入和回显问题，一般是以行结束，或是以某个结束符为终命令终止标识。System.out 和System.err就用于标准的输出和错误输出，System.in用于标准的输入接受，一般情况下都是指键盘。
   如果接受参数输入，一般的程序结构如下：

BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
System.out.println("==Please input password==：");
String pass = in.readLine();

   输入的时候显示屏自动进行输入回显。这个时候如果遇到输入密码等敏感数据的时候，就无法用*或是#这样的符号进行回显屏蔽，容易暴露安全问题。
   解决的可能想法：
   1. 通过监听键盘事件，对输入的回显进行截获取，把回显进行屏蔽，但是监听器如何知道何时是输入密码，何时是输入普通数据？比较难以控制，而且这种监听应该是线程化的，可能会存在一些意想不到的问题。
   2. 如果用纯Java难以实现，那么是否可以使用其它语言的功能进行补充，比如JNI，或是Windows下面的Dos脚本，Linux平台的Shell脚本来进行补充。不过这样就不太平台无关了。
   3. 可能sun发现了这个不足之处，从1.6版本开始，增加了一个java.io.Console类，代表与当前 Java 虚拟机关联的基于字符的控制台设备，这个Console是对原来System.in这种不足的补充，提供了像readPassword()等这样的实用方法，具体请参考API文档，就是专门用于对敏感信息的读取。但是这是基于Java1.6的，如果有些场景受限制，不能使用1.6，那么还是无法解决上面的问题。后来查阅了一下Console类的实现方式，想直接把它的实现方式移植到1.4.xx上是比较难的，因为用到了一些高版本的新特性。使用Console要注意的是：虚拟机是否具有控制台取决于底层平台，还取决于调用虚拟机的方式。如果虚拟机从一个交互式命令行开始启动，且没有重定向标准输入和输出流，那么其控制台将存在，并且通常连接到键盘并从虚拟机启动的地方显示。如果虚拟机是自动启动的（例如，由后台作业调度程序启动），那么它通常没有控制台。如果你在Eclipse里面启动程序调用Console，那么通常是没有控制台，还是得从外部的命令行方式才能调用得到。
   总体想一下，感觉应该还是从第2点出发，牺牲掉一点通用性，这样才能满足这种功能需求。

寒武纪 2008-05-23 09:41 发表评论