也许朋友们会以为这是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的公用类,具体的写法如下:
java 代码
- public class Context {
-
- private static WebContext getContext(){
-
- return WebContextFactory.get();
-
- }
-
- public static HttpServletRequest getRequest(){
-
- return getContext().getHttpServletRequest();
-
- }
-
- public static HttpServletResponse getResponce(){
-
- return getContext().getHttpServletResponse();
-
- }
-
- public static HttpSession getSession(){
-
- return getContext().getSession();
-
- }
-
- }
-
然后写一个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造成的错误呢?我将在下一篇文章中讨论。
分享到:
相关推荐
DWR(Direct Web Remoting)是一种Java技术,用于在Web应用程序中实现JavaScript和服务器端Java代码之间的直接异步通信。这个“DWR入门程序---计算输入的两个数之和.rar”压缩包文件很可能是为了演示如何使用DWR来...
- DWR会自动生成JavaScript接口,使得在客户端可以直接调用服务器端的方法,无需手动编写AJAX代码。 - 在HTML页面中引入DWR生成的JavaScript文件,然后通过这些接口调用服务器端方法。 4. **Ajax请求与响应处理**...
1. **远程方法调用(Remote Method Invocation, RMI)**:DWR允许JavaScript直接调用服务器端的Java方法,就像它们是本地函数一样。这使得开发者能够轻松地在客户端执行复杂的业务逻辑,而无需编写大量的AJAX代码。 ...
4. **生成JavaScript API**:DWR会根据配置自动生成JavaScript API,这些API可以直接在浏览器中使用,调用服务器端的方法。 5. **前端调用**:在HTML或JavaScript代码中,引入DWR生成的JavaScript文件,然后就可以...
Direct Web Remoting (DWR) 是一个开源的Java库,它允许在Web应用程序中实现JavaScript与服务器端Java代码之间的直接交互。DWR的核心目标是简化AJAX(Asynchronous JavaScript and XML)开发,使得前端和后端可以更...
DWR(Direct Web Remoting)是一种Java库,用于在Web应用程序中实现实时的、双向的JavaScript和服务器端代码交互。这个技术允许开发者在客户端浏览器上执行服务器端的方法,就像它们是本地JavaScript函数一样,极大...
- **简介**:DWR的核心理念是使JavaScript能够像调用本地方法一样调用服务器端的Java方法,极大地简化了Ajax编程。 - **第一个DWR程序:HelloWorld** - 将DWR库添加到项目中。 - 配置`web.xml`和`dwr.xml`文件,...
Direct Web Remoting (DWR) 是一个开源的Java库,它允许JavaScript在浏览器端与Java在服务器端进行交互,从而实现动态的Web应用程序。在这个"**dwr实现的服务器推demo**"中,我们看到一个实例,展示了如何利用DWR的...
DWR(Direct Web Remoting)是一种简化Ajax应用程序开发的技术框架,它允许客户端JavaScript直接调用服务器端的Java方法,从而实现了浏览器与服务器之间的远程调用。DWR的应用场景主要集中在那些需要频繁进行客户端...
Direct Web Remoting (DWR) 是一个开源的Java库,它允许JavaScript在浏览器端与服务器端的Java对象进行交互,从而实现动态Web应用程序。DWR通过AJAX技术提供了一种简单的方法来更新网页的部分内容,而无需刷新整个...
- **编写JSP**:创建一个JSP页面,引入DWR JavaScript库,并编写必要的JavaScript代码来调用服务器端的方法。 ##### 3.3 示例:HelloWorld 这是一个简单的示例,用于演示如何使用DWR实现客户端与服务器之间的通信...
Direct Web Remoting (DWR) 是一个开源Java库,它允许Web应用程序在客户端JavaScript和服务器端Java之间进行双向通信,从而实现动态、实时的Web交互。这个“dwr-任何java类-测试”主题着重于如何利用DWR来调用Java类...
DWR,全称Direct Web Remoting,是一个JavaScript框架,旨在简化Web应用程序中的客户端与服务器端交互。它允许开发者在浏览器中直接调用Java方法,就像操作本地对象一样,从而实现AJAX(Asynchronous JavaScript and...
DWR(Direct Web Remoting)是一个强大的开源框架,它允许Web应用程序通过JavaScript与服务器端的Java对象进行直接交互。这个框架极大地简化了Ajax(异步JavaScript和XML)开发,使得前端开发者可以像操作本地对象...
Direct Web Remoting (DWR) 是一个开源的Java库,它允许JavaScript在浏览器端与服务器端的Java对象进行交互,从而实现动态的Web应用程序。这个压缩包文件“dwr简单示例(完整web工程)”显然是一个包含了完整配置和...
4. 编写业务逻辑:在服务器端编写处理前端请求的方法,利用Hibernate进行数据库操作。 5. 调试与测试:确保前端与后端的交互正常,数据处理无误。 通过以上分析,我们可以看出"ext-dwr-hibernate"整合的关键在于...
在DWRDEMO中,你可能会看到如何配置DWRServlet,如何在`web.xml`和`dwr.xml`中设置参数,以及如何在JavaScript中使用DWR提供的API(如`DWREngine`,`RemoteProxy`等)来调用服务器端的方法。同时,后端的Java类将...
通过将服务器端逻辑封装成JavaScript库的形式,不仅提高了开发效率,还增强了应用程序的交互性。此外,DWR还支持多种数据格式(如JSON、XML等),使得开发者可以根据实际需求灵活选择数据交换方式。总之,DWR为构建...