小试ThreadLocal想到“隐式参数”模式最近同事想通过自定义函数来输出国际化文字。比如：${my:i18n(login.use
小试ThreadLocal想到“隐式参数”模式
最近同事想通过自定义函数来输出国际化文字。比如：
${my:i18n('login.userid')}.
EL支持我们自定义这样的函数，问题是这个函数没法获取request对象，不知道当前页面的语言。
由此我想到threadlocal也许可以解决这个问题。
我的思路是做一个filter，每次都把request引用保存在一个threadlocal变量里。然后在上述的i18n自定义函数里读取这个threadlocal变量，得到request。
代码如下：
1 定义一个类读写threadlocal变量public class ThreadAttributes { private static ThreadLocal<Map<String, Object>> threadAttribues = new ThreadLocal<Map<String, Object>>() { protected synchronized Map<String, Object> initialValue() { return new HashMap<String, Object>(); } }; public static Object getThreadAttribute(String name) { return threadAttribues.get().get(name); } public static Object setThreadAttribute(String name, Object value) { return threadAttribues.get().put(name, value); }}2 在一个filter里写入requestpublic void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; ThreadAttributes.setThreadAttribute("request", req); .....}3 读取requestHttpServletRequest request = (HttpServletRequest)ThreadAttributes.getThreadAttribute("request");
由此，我想到其他类似的问题。
跟web相关的里的方法，往往都有request参数；
跟数据库相关的方法，往往都有连接或事务的参数；
跟绘图相关的方法里，往往有一个绘图设备参数；
。。。。
如今分层架构非常普及，如果这些非常令人讨厌，但又的确需要的参数，都用上述的方案来在堆栈之间传递，将是一个不错的主意。事实上，spring已经让我们尝到了甜头，解放了我们的DAO对象，看不到connection参数。
我这里且叫它为“隐式参数”模式。
楼上的想法不错，我支持你！
不过这不是什么隐式参数模式，呵呵，这种思想其实被广泛应用，一般我们称之为Context，也就是上下文。比如在JSF中，比如EJB中，都包含着这种思想。它区别于常见的层的概念或者说设计思路的
当然了，其他朋友所担心的滥用也是可以理解的，不过任何一个好的设计都来自于思想的理解。楼主有了第一步，建议拓广一下思路。
18 楼 vlinux 2009-05-06 如果业务层和表示层不在同一个应用中，而是通过rmi、soap调用，就歇菜了。 19 楼 presses 2009-05-06 ThreadLocal是针对特定场景的特效药而不是万甘油。
一方面,很多模式的实现都用上了ThreadLocal,例如OpenSessionInView。
另一方面，ThreadLocal不能滥用。因为什么？因为他隐形，隐形的东西容易让代码不清析。像当年的"goto"？
所以我建议,ThreadLocal可以用，但要限制在系统架构层等一些框架类中，而且这些基础类不能直接爆露ThreadLocal给一般模块调用。
另外要注意，在servlet容器中使用时，在请求过程中注入的对像，要在请求完毕前，完全清理。因为servlet容器的实现，大多用线程池实现。不同的表求有可能共用一个线程。
