DWR帮助说明－服务器端程序的编写

也许朋友们会以为这是DWR官方发布的什么帮助，但非常遗憾这不是。现在不少朋友在使用DWR开发项目，我也是其中之一，但苦于关于DWR的帮助文档实在太少，很多问题都不得不自己去钻研DWR的源码才能解决或理解。经过一段时间的苦苦钻研，总结出那么一点点心得，现在从DWR源码实现的角度详细讲解DWR的使用，写出来与大家分享。今天我谈一谈DWR服务器端代码的编写。

前面我谈到，dwr使我们编写的代码完全省略掉了MVC层，也就是说我们可以从过去需要在MVC层做的form与vo的数据转换、为每个页面访问提供相应的action和一系统复杂的配置都省略掉了，似乎直接就从页面到bus了。但是，这样的省略似乎来得太快了点儿，一下子还真不太适应。我最初就有这样的感觉，其中一些以前应当在action中执行的功能，现在需要另想办法，最常见的就是获取request、response、session和权限校验。

获取request、response和session

据说在其它一些ajax的产品中没有提供对request、response和session的获取，需要自己写程序去取得，但在dwr中就完全可以没有这个顾虑了。在dwr中有一个WebContextFactory类，静态调用这个类的get()方法就可以得到dwr的另一个类：WebContext。在WebContext中，你可以看到getHttpServletRequest()、getHttpServletResponse()、getSession()等方法，通过它们就可以顺利地得到request、response和session了。

虽然dwr可以方便快捷地让我们获取request、response和session，但另一个问题我觉得值得我们思考：我们应当在哪个层次上获取它们？我们使用dwr的方便之处是没有MVC层，也就似乎是说从页面端直接就到达了bus层。虽然实际并不是这样，但从页面到bus之间的工作都是dwr在为我们完成的，我们没有对这部分编码。这样，我们似乎也就可以直接在bus层通过dwr提供的方法直接引用和处理request、response和session好 了。当然可以这样处理，但我认为这样做不是一个好的设计，因为这样做违背“不要跟陌生人说话”原则。众所周知，“不要跟陌生人说话”是软件设计模式中一个 重要的原则，它要求我们在设计某个类的过程中，不要去访问与自己职能不相关的类，以便保持自身功能的独立性。我们传统的对bus层其职能的定义，应当是实现某个业务功能。为了实现这个业务功能也许需要一些数据，比如从request获取数据，从数据库获取数据。但是这些数据是如何获取的，都不是bus层关心的问题。它只在意从自己参数中，或者调用某个接口来获得数据，这就是bus的职能。

如果我们在写bus的时候加入了通过dwr获取request、response、session的代码，那么bus就开始与陌生人说话了，也就是做了一些与自己职能无关的工作，访问了一些不应该访问的类。这样做的后果就是，如果今后我们希望将这些bus重用到别的项目中，而这个项目又不使用dwr，或者在本项目中需要重用某个bus到别的功能中，而这个功能不使用dwr，那么这样的设计将使这种重用变为不可能。

说了这么半天虚的，举一个例子来实际说明一下该怎样设计。在一个项目中需要使用request、response、session的地方最常用的就是获取登录用户的用户信息，如他的用户名、所在部门、拥有权限等。这个功能在各个bus中可能都用得到，而且功能比较固定，因此我们将它抽象出来做成一个公用类。在写这个公用类前我们先写一个获取request、response、session的公用类，具体的写法如下：

然后写一个UserInfoUtil的公用类，引用Context来获得session中的用户信息，供其它bus调用。你也可以引用Context写出其它类来获取和操作request、response、session，总之就是不要写到bus中。

权限校验

前面谈完了request、response、session的问题，紧跟着我们就来谈权限校验的问题。在dwr中似乎页面端可以直接就去访问bus的各个方法，这从信息安全的角度讲是非常危险的。我们必须对页面访问bus进行安全校验。根据前面的思路，这样的校验不应当写在bus中，而是抽象出来形成公用类。就这个问题我在网上搜索了一下，有不是网友讨论过这个问题，总结一下有2种思路：一种是为dwr设计一个filter，另一种是运用aop为bus设计拦截器。对比这2种思路，我更欣赏后一种思路，因为它更灵活多变，也更适合与spring结合使用。我们再展开分析一下它的优势所在吧。

首先，我们可能在不同的项目中会对为项目提供多种权限校验的机制，比如通过部门级次进行校验、通过分配给用户的功能进行校验、通过用户的特殊身份（总经理、局长等）进行校验等。这些校验机制并不是每个bus都需要使用的，有的bus使用这种机制，有的bus使用那种机制，有的bus同时使用好几种机制。

另外，我们还可能出现，一些特殊的功能需要单独为它设计一个权限校验机制，这个机制只作用与它自己。

还有一种情况是权限校验机制需要分不同的方法进行校验，如增删改一个校验机制，而查询是另一种校验机制。

然后，我们不希望在开发过程中加上权限校验机制，这无疑会为我们的调试增加许多的不便。

总结以上所有对权限校验的需求，使用filter似乎有些力不从心，而aop却完全可以胜任。在系统设计完成以后再通过配置来添加系统所需的诸如权限校验、事务处理等功能是aop的基本思想。而Aop可以在spring的配置文件中配置哪些bus使用哪些校验拦截器，也可以为一个bus配置多个拦截器。Spring提供了通过bean名称匹配的方式（诸如*Bus、*Service）为所有bus配置拦截器，也可以单独为某个bus配置拦截器。另外，你还可以采用方法名匹配的方式（诸如create*、update*、delete*）决定哪些方法采用哪些权限拦截器。看了这些是不是觉得眼熟呀，对，这种方式正好是与spring的事务拦截器是完全一样的方式进行操作的。

Dwr的事务处理

我在前面的文章中提到，在页面端dwr提供了dwr.engine.beginBatch()和dwr.engine.endBatch()来进行事务处理。如果你在项目中使用了hibernate，可以在web.xml中添加org.directwebremoting.hibernate.H3SessionAjaxFilter就可以实现hibernate的事务处理了。但我认为这没有什么用，因为我们通常在bus层通过spring的事务处理机制就可以完美地完成事务处理了，dwr的事务处理则似乎有些多此一举。

Dwr的调试功能

最后我要提到的，就是dwr最重要的，也是dwr提供给我们最好用的一个功能：调试功能。首先我们要打开调试功能，也就是在web.xml中，将DwrServlet的debug参数设置为true，然后在浏览器中访问http://[你的项目地址、端口及其项目名]/dwr，就可以显示出你在dwr中注册的所有有效的bus，点击某个bus就可以显示dwr侦测到的该bus的所有方法。如果这些方法使用到某些类参数或返回值，以及哪些方法被你禁用了，在该页面中都会提示你。另外，在该页面中还会提示你，要使用该bus，你应当在页面中引入哪些js。点击这些js的链接并选择保存，你还可以看到dwr为你动态生成的js的内容，特别是那个XxxBus.js的内容。这个调试功能在网上很多dwr的文章中都详细介绍过，我就不再累赘了。

Dwr的调试功能完全改变了我们的编程方式，至少我是这样认为的。它让我们可以将前台与后台的编写和调试完全分离。首先，我们先编写后台程序，就是哪些bus、dao以及相关的类。在编写的过程中，我们完全可以不用启动Tomcat、Weblogic等应用服务器，而是编写main函数直接运行，大大提高我们运行调试的效率。后台程序编写完成以后，通过dwr的调试页面在应用服务器确认所有的bus方法在服务器端正常运行，就可以在完全不用重启服务器的情况下直接编写前端页面程序。这样的编程方式完全就没有了过去一遍一遍重启服务器的痛苦，怎能不说是一种完全的改变呢？

除此以外，与其它框架一样，我们在运用dwr开发项目的时候同样会出现一些错误。在这些错误中，有的是因为dwr自身的bug所致。如何解决dwr的bug造成的错误呢？我将在下一篇文章中讨论。