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

转载 2007年09月27日 09:42:00

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

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

获取requestresponsesession

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

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

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

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

java 代码
  1. public class Context {   
  2.   
  3.        private static WebContext getContext(){   
  4.   
  5.               return WebContextFactory.get();   
  6.   
  7.        }   
  8.   
  9.        public static HttpServletRequest getRequest(){   
  10.   
  11.               return getContext().getHttpServletRequest();   
  12.   
  13.        }   
  14.   
  15.        public static HttpServletResponse getResponce(){   
  16.   
  17.               return getContext().getHttpServletResponse();   
  18.   
  19.        }   
  20.   
  21.        public static HttpSession getSession(){   
  22.   
  23.               return getContext().getSession();   
  24.   
  25.        }   
  26.   
  27. }   
  28.   

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

权限校验

前面谈完了requestresponsesession的问题,紧跟着我们就来谈权限校验的问题。在dwr中似乎页面端可以直接就去访问bus的各个方法,这从信息安全的角度讲是非常危险的。我们必须对页面访问bus进行安全校验。根据前面的思路,这样的校验不应当写在bus中,而是抽象出来形成公用类。就这个问题我在网上搜索了一下,有不是网友讨论过这个问题,总结一下有2种思路:一种是为dwr设计一个filter,另一种是运用aopbus设计拦截器。对比这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中,将DwrServletdebug参数设置为true,然后在浏览器中访问http://[你的项目地址、端口及其项目名]/dwr,就可以显示出你在dwr中注册的所有有效的bus,点击某个bus就可以显示dwr侦测到的该bus的所有方法。如果这些方法使用到某些类参数或返回值,以及哪些方法被你禁用了,在该页面中都会提示你。另外,在该页面中还会提示你,要使用该bus,你应当在页面中引入哪些js。点击这些js的链接并选择保存,你还可以看到dwr为你动态生成的js的内容,特别是那个XxxBus.js的内容。这个调试功能在网上很多dwr的文章中都详细介绍过,我就不再累赘了。

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

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

 

相关文章推荐

dwr服务器端反推demo

  • 2013年05月03日 17:55
  • 1.15MB
  • 下载

DWR入门教程2 服务器端push技术

DWR入门教程2 服务器端push技术
  • jing_le
  • jing_le
  • 2015年03月05日 14:56
  • 730

dwr3与struts2整合,实现服务器端推送技术,实现多人聊天功能

1,首先放入struts2和dwr的jar包,这个想必大家都知道了吧! 2,下面是web.xml的全部配置信息,因为当初是ssh2一起整合的,所以会有spring的配置信息, ...
  • Txy0226
  • Txy0226
  • 2014年02月27日 10:03
  • 1074

DWR实现JAVA服务器端向客户端推送消息

1.配置web.xml       dwr       org.directwebremoting.servlet.DwrServlet                 debug ...

DWR3实现服务器端向客户端精确推送消息

研究了一天半,终于模拟出了这个功能,网上DWR的资料不少,但是真正实现客户端向服务器端精确推送消息的只有两篇文章。但是代码都只有一部分,向我这种刚开始学习DWR的人来说要看懂真的蛮难。不过即便如此,h...

DWR实现服务器端向客户端推送消息

1.简介 DWR(Direct Web Remoting)是一个用于改善web页面与Java类交互的远程服务器端Ajax开源框架,可以帮助开发人员开发包含AJAX技术的网站。它可以允许在浏览器里的代...

通过JAVA编写DOMINO服务器端插件程序

通过JAVA编写DOMINO服务器端插件程序   /*    This is an example of a Notes Server Addin written in Java.    ...

SAE-servlet---服务器端程序编写

我采用的是java servlet,最开始在本机tomcat上运行,后来发现SAE是jetty的环境,又去部署了jetty, 现在是在阿里云上部署,直接通过阿里云上安装的tomcat进行部署应用。 ...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章: DWR帮助说明-服务器端程序的编写
举报原因:
原因补充:

(最多只允许输入30个字)