动态代理在WEB与JDBC开发中的应用

WEB案例

目前有一个2005年开始，基于Struts1的Web项目A，其验证部分依赖于主站的SSO（单点登录）。在请求站点A的时候，用户会被强制带去做SSO验证，通过身份验证后后，主站会自动地把请求转发至A站点，并在request header中添加了用于保存登录用户ID的新属性SM_USER，然后A站点根据用户ID提供相应的服务。由于该项目是一个既存项目，所以其中残余大量像下面一样的测试代码。

1. String user_id = request.getHeader("XX_USER");
2. if (user_id == null) {
3. user_id = "my_hard_coded_user_id";
4. }
5. UserProfile userProfile = new BizDao().getUserProfile(user_id);

其根本原因是在本地测试的时候无法于生产环境的SSO对接，只有把代码提交至公共的DEV服务器、UAT服务器或PROD服务器后，才能享受SSO为A站所提供的XX_USER数据，所以程序员在无法取得header数据的情况下，直接简单粗暴地对本地环境进行了硬编码处理。在只有几个人的小团队，这样的处理可能看起来也无所谓，但长年下来经手的人数也相当可观了，很多人都习惯使用自己的ID做测试，所以在SVN的历史版本中，硬编码的ID从A改到B、改到C、改到D……

问题分析

每个人都根据自己的喜好选择了使用自己的ID或是他人的ID，那么是否有一种办法可以统一接口一劳永逸呢？可能最容易想到的就是HttpServletRequest.setHeader，可惜HttpServletRequest并没有这样的API，为啥？个人猜测可能是因为request源于客户端，服务器端应该保持请求的原始性、纯净性和无毒性吧，而HttpServletResponse（http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html）则是在应用程序的控制之下，所以程序员可以对其任意践踏，setHeader、addHeader以及getHeader、getHeaders、getHeaderNames。既然没有API可用，直接进行包装代理吧，在Google的帮助下我们可以找到现成的方案来对request中的header进行重新定制，重点是HttpServletRequestWrapper类的实现。

http://vangjee.wordpress.com/2009/02/25/how-to-modify-request-headers-in-a-j2ee-web-application/

其实这个方案是在我实现动态代理方案之后找到的，两者思路几乎是一样的，都是对原始request进行包装代理，重新实现getHeader方法。

解决方案

不废话，直接上代码！

1. private static class RequestInvocationHandler implements InvocationHandler {
2. private HttpServletRequest wrappedRequest;
3. public RequestInvocationHandler(HttpServletRequest r) {
4. wrappedRequest = r;
5. }
6. public static String dummyData = "my_hard_coded_id";
7. public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
8. if ("getHeader".equals(method.getName()) && args.length == 1 && "SM_USER".equals(args[0])) {
9. return dummyData;
10. }
11. return method.invoke(wrappedRequest, args);
12. }
13. public static HttpServletRequest createRequestWapper(HttpServletRequest r) {
14. if (null != r.getParameter("u")) {
15. dummyData = r.getParameter("u");
16. }
17. return (HttpServletRequest)(Proxy.newProxyInstance(HttpServletRequest.class.getClassLoader(),
18. new Class[] {HttpServletRequest.class},
19. new RequestInvocationHandler(r)));
20. }
21. }

上面代码实现了对Request对象的代理，所有针对Request对象的调用都需经过invoke方法。在invoke方法中，我们可以针对不同的方法签名进行更为细粒度的控制。比如在WEB案例中提到的问题，可以专门针对getHeader方法进行重新定制，本来Request Header中并无该数据，但我们可以硬生生地“造”出数据。另外除了可以“造”出测试数据外，还可以通过请求中携带的参数“u”动态地进行数据修改，这样就实现了用户切换的功能。

既然代理类的问题解决了，下面该谈谈应在何时何地植入代理对象了。何时何地可以理解为切入时机，其实最初的是在org.apache.struts.action.RequestProcessor中植入代理对象的，但是在使用过程中发现该实现有一个弊端，那就是在非Struts请求时无法使用代理对象，比如直接访问JSP文件或是其它Servlet所提供的服务路径。这时自然而然地想到Filter，而使用Filter也是一痛，加入一个全新的Filter吧，有点破坏的整体设计的感觉，而放入其它Filter之中的话，看起来又不伦不类。但好歹是测试用，这两个方案可以折衷选择其一，具体实现如下。

1. public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException
2. request = RequestInvocationHandler.createRequestWapper((HttpServletRequest)request);
3. chain.doFilter(request, response);
4. }

整体工作流程如下，用户首先发出请求，然后request对象在filter中被替换成代理对象，替换后的request被传入doFilter方法，之后不论是Servlet、Struts还是JSP，它们用到的都是我们定制的Request对象。

1. +---------+         +---------+
2. |         |         |         |
3. Request   |         | +-----> | Servlet |
4. --------> |  Filter |         |         |
5. | +----+  |         |  Struts |
6. | Request |         |         |
7. Response  |      is |         |         |
8. lt;--------+ | wrapped |         |         |
9. |    here | <-----+ |         |
10. |         |         |         |
11. +---------+         +---------+

后记

当然，如果想要修改request对象不止这一种方法，比如正统的方式是定义一个HttpServletRequestWrapper来重新定义request，具体案例请参考http://vangjee.wordpress.com/2009/02/25/how-to-modify-request-headers-in-a-j2ee-web-application/

JDBC案例

背景描述

我们先看一下项目所面临问题以及期望解决方案。在作者所接触的这个项目中，直接使用原始JDBC技术，Java.sql.PreparedStatement和java.sql.ResultSet几乎占领了数据访问层，没有半点OR Mapping的迹象，看起来是不是很悲催？命啊～在项目开发至一半的时候，突然发现要对日文字符进行支持，而在之前一直使用英文进行测试。好了，问题来了，一个编码为8859_1的数据库怎么来接收Java中的UTF-8呢？并且很多CRUD功能已经完成，每个实现中涉及的字段数目相当之大，难道针对每个字段逐一调整不成？

问题分析

针对上面描述的情况，我们先做一个简单的分析。目前所面临的问题可以归为两种类型，第一类就是乱码的问题，这个可以通过重新编码得到解决；第二类则是面临大量的代码实现，如果对所有内容进行调整的话，很多功能就得重新测试，成本较高，但确实可行。

针对乱码问题，从实现的角度考虑，可以分别针对输入数据和输出数据进行编码转换。是在使用PreparedStatement的时候，对所有调用setString的地方进行编码转换；而对于数据读取的情况，可以对ResultSet.getString所返回的结果字符串进行编码转换。下面以UTF-8转8859_1为例子，实现编码转换（逆向转换只需交换编码名称的位置即可）：

1. new String(new String("abc").getByte("UTF-8"), "8859_1")

如果以这种方式对每处PreparedStatement.setString和ResultSet.getString的调用都进行编码转换操作的话，工作量不仅繁重，而且不利于代码的维护与移植。从API上看，其实我们可以针对setString和getString进行“HOOK”，使用代理模式比较适合，动态代理最为适宜。

解决方案

编码问题解决了，利用动态代理统一地对setString和getString接口进行自制，让所有的调用都在我们的控制之下还何愁不能统一江山！

1. public static ResultSet createResultSetJPWrapper(ResultSet rs) {
2. return (ResultSet)(Proxy.newProxyInstance(ResultSet.class.getClassLoader(),
3. new Class[] {ResultSet.class},
4. new ResultSetJPWrapper(rs)));
5. }
6. private static class ResultSetJPWrapper implements InvocationHandler {
7. private ResultSet wrappedResultSet;
8. public ResultSetJPWrapper(ResultSet rs) {
9. wrappedResultSet = rs;
10. }
11. public Object invoke(Object proxy, Method method, Object[] args)
12. throws Throwable {
13. Object result = method.invoke(wrappedResultSet, args);
14. if ("getString".equals(method.getName()) && null != result) {
15. result = CommonUtils.convertCharset((String)result, ISAConstants.CHARSET_8859_1, ISAConstants.CHARSET_UTF_8);
16. }
17. return result;
18. }
19. }
20. public static PreparedStatement createPreparedStatementJPWrapper(PreparedStatement pstmt) {
21. return (PreparedStatement)(Proxy.newProxyInstance(PreparedStatement.class.getClassLoader(),
22. new Class[] {PreparedStatement.class},
23. new PreparedStatementJPWrapper(pstmt)));
24. }
25. private static class PreparedStatementJPWrapper implements InvocationHandler {
26. private PreparedStatement wrappedStatement;
27. public PreparedStatementJPWrapper(PreparedStatement pstmt) {
28. wrappedStatement = pstmt;
29. }
30. public Object invoke(Object proxy, Method method, Object[] args)
31. throws Throwable {
32. if ("setString".equals(method.getName()) && args.length == 2 && null != args[1] && String.class.equals(args[1].getClass())) {
33. args[1] = CommonUtils.convertCharset((String)args[1], ISAConstants.CHARSET_UTF_8, ISAConstants.CHARSET_8859_1);
34. }
35. return method.invoke(wrappedStatement, args);
36. }
37. }

接下来就是在需要使用PreparedStatement和ResultSet的地方进行重构。

1. // 重构前
2. PreparedStatement stmt = conn.prepareStatement(sql);
3. // 重构后
4. PreparedStatement stmt = DBUtils.createPreparedStatementJPWrapper(conn.prepareStatement(sql));
5. // 重构前
6. ResultSet rs = stmt.executeQuery();
7. // 重构后
8. ResultSet rs = DBUtils.createResultSetJPWrapper(stmt.executeQuery());

重构后不论是stmt还是rs，setString和getString都会被我们定义的动态代理所劫持，在数据输入前或数据输出后重新编码，而这一切对于开发人员来说一切都是透明的，并且不会对现有逻辑造成污染。

后记

这里谈论的只是动态代理应用案例，并不意味着必须使用动态代理是该案例中解决问题的唯一方案。其实动态代理在这里不一定是最佳的实现方案，如果可以的话最好对数据库进行重新设置修改默认编码，或者是在应用层统一编码，但这些往往都不适用于一个经过十多年、几十人、且风格各异且“烂”的发臭的项目了。其实实际的数据库VARCHAR类型中存放的字符串编码五花八门，EUC-JP/SHIFTJIS/UTF-8/8859_1，并且这些编码可能同时存在于一张表，要了命了！