原文: Web框架对比: Wicket vs Struts
一、概貌
Wicket是基于web应用框架的高级组件,其主要特点:
* 在HTML和java之间的明确分隔
* OO组件模式
* 自动状态管理
* 高度生产化
* 低学习投入
* 屏蔽Servlet API、HTTP协议细节
* 无需XML配置文件
* 易于构造可重用组件
Struts是以Model2 MVC 为蓝本构建的web应用框架。其工作围绕着处理HTTP请求的action类来完成。配置方式采用XML文件。
下文将对Wicket和Struts在体系、HTTP请求处理、Servlet API和HTTP协议抽取、状态管理、配置这六方面进行比较。
二、比较第一方面:体系
Struts体系基于解释每个HTTP请求并将其定向到某个处理该类型请求的指定Action类。每个Action类将处理后的结果返回,并决定下一步走向——通过转发或者重定向到另一个Action或者将控制权交给输出HTML的JSP页面。从技术较大来讲,虽然每个部分之间做到了很好的解耦,但是基于HTTP请求的处理模式可谓与时代不符(与wicket相比就是过时了)。两大原因如下:
* Struts并不是真正意义上的纯粹面向对象,每个Action类定义了一个abstraction(抽取),但是abstraction是由HTTP协议的请求机制决定的,而并非面向对象的分析。
* 除非我们在java代码中直接输出HTML(当然除非我们疯了),那么为了输出HTML我们就要学习另外的主流技术,比如JSP和自定义tag。使用在JSP中使用tag并非易事,尤其是当我们把这项工作交给美工小组时,这会直接导致两个结果:JSP代码被他人作的一沓糊涂,或者是我们自己完成这项任务。
而Wicket的处理方式则不同,从整体来讲应该说是更加优雅些。它采用面向对象的组件技术实现web与用户的交互(这点有些如Swing)。在Wicket中的每一页是由若干的使用组合设计模板生成的组件构成。页面和组件各自渲染自己,并直接或者间接的与markup文件(标识文件,形式就像JSP)关联。当HTTP请求到来时,这些请求被转换、传递到组件上的相应事件中来,这一点与微软的VS很相象。所以Wicket能够解决struts体系中存在的问题:
* Wicket是完全面向对象的。我们可以利用组件的继承性设计自己的应用。这里不需要为处理HTTP协议的请求/响应而作任何工作。
* Wicket所使用的markup文件与纯粹的HTML很接近,所以容易上手使用。Wicket在markup文件中所引入的内容非常整洁,并符合XHTML标准。任何了解HTML的开发者都可以如编辑HTML文件那样编辑Wicket的markup文件,就好似他并不知道这是Wicket的markup文件一样。
三、HTTP请求处理
在Struts中,一个HTTP请求被接收后,Struts将在配置文件中查找request path和相应的Action类。如果这些已经被配置好了,它将将提取请求参数放入到ActionForm bean中,并执行一些验证。然后HTTP请求、回应和ActionForm对象都将作为参数传入到Action类中。从这点可以看出Action的开发者掌握着应用的方方面面:他们必须处理HTTP session,维护HTTP请求和session的属性,并在action执行完时建立需要返回的信息,最后还要返回相应的ActionForward以使struts知道下一步在哪里。假如此时ActionForward将控制权交给了JSP页面,开发者就要使用struts自定义的tag库编写JSP代码。如此繁复的工作环节很容易出现错误,而且struts还需要三个位置保持一致:struts XML配置文件、java Action类、JSP自定义tag。
而在Wicket中,一个HTTP请求被接收后,Wicket将确认HTTP所请求的那个页面和在这个页面关联的组件。如果请求的目的是form,Wicket将自动提取请求参数、验证参数、进行一些预先规定好的类型转换、设置form组件中的model(模式,这里用法与MVC中类似,但有不同)值;接着转化请求为相应类型的事件、调用目标组件上的相应事件侦听器,这样就会导致事件处理代码运行来执行业务逻辑;然后,事件处理器还将指定下一步页面的位置,被指定的页面将初始化(如果页面从未被初始化的话)并自动渲染;渲染处理将按照顺序访问每个页面组件,要求它们进行自我渲染。在markup文件中能够组件仅通过名字与HTML元素进行映射。
Wicket出色的原因:
* 每个组件知道如何处理自己事件。因此我们只需要将组件放到页面上,编写事件处理器就行了。如果一个页面中存在20个能引发事件的不同的组件,我们除了进行将它们添加到页面上的工作外没有别的工作。但如果在struts中,我们可能需要建立20个不同的Action类或者一个具有20个分支语句的Action类,并要在XML配置中逐一添加。
* Wicket带给了我们考虑组件/事件重用的机会。而不用将注意力放到如何处理HTTP请求和回应上。
* 与struts相比使用Wicket会降低我们的代码量,这正是重用组件带来的益处。Wicket本身不使用任何的XML配置文件。只需要修改web容器的web.xml文件中的servlet声明部分。
假如我们曾经编写过Windows API、并用过Visual Basic或者Borland Delphi的话,下面的比较会更加让人印象深刻。使用struts开发就像使用Windows API一样:接收原始消息,解码原始消息,然后再处理这些消息。由于Windows API是基于消息循环工作的,所以系统除了消息回应外不期望任何的返回值。
从另一方面看,Dephi在TApplication类中隐藏了Windows消息循环,使开发人员围绕着TApplication类建立其他的类。原始的系统消息就这样被Dephi内建类接收,被内建类解析并被确定其接纳者。消息被转换为一个事件,并被传送到某个特定的对象。
如Windows应用程序一样,Wicket应用也具有服务于文本和HTML模板的资源文件。从这点看,Wicket象用Delphi做桌面开发一样被用来做web开发。
四、Servlet API和HTTP协议的抽取
Struts没有隐藏Servlet API和HTTP协议的细节。为了使用Struts,我们必须乐于和HTTPServletRequest、HttpServletResponse 和HttpSession类打交道。并围绕着请求和回应建立应用。这便是所有Model2 MVC wen框架与生俱来的弱点。
正如上面说的,Wicket隐藏了Servlet API和HTTP协议的细节。对于一些应用,我们甚至触及不到这些细节。甚至对于非常复杂的应用,我们也仅使用适当的Wicket协议抽取类。而经常用到的是java组件类、POJO业务模型、纯HTML标记文件。
五、状态管理
使用Struts开发,我们将获得全部的状态管理权。这对于建立大规模的、高升级空间的、集群应用来讲是很好的,因为我们将获得对HttpSession上每件事物的控制权。但是对于中小型应用,我们将没有缘由编写一些额外的代码。这样将导致应用变得复杂和编写费时。
在状态管理上,Wicket可以作为一个不错的选择。Wicket框架默认代管所有的组件状态。这对于中小型应用,在状态管理上的代码量几乎为0。但是Wicket也提供了一些API使我们进行标准状态管理和实现自己的状态管理。这样,即使是大型应用,我们也能够全权掌握状态管理。事实上,即使在使用Wicket编写大型应用时,通常也是先让Wicket代管所有的状态,然后再慢慢的实现自己定义的状态管理以提高应用性能。
六、配置
不言自明,Struts需要一个XML文件:定义对HTTP请求和响应的映射和所有的ActionForm对象等。这个文件可能非常大而且复杂。而新版本的Struts提供了将这个文件分解为多个模块的方法,虽然这样可以将模块分类,但是这样同样要维护许多的小文件。
Wicket不需要配置文件。Wicket通过一个简单的应用配置类或者通过编写web容器的web.xml文件中Servlet init参数来完成程序的初始化。而HTTP请求到组件事件的映射、组件如何输出HTML等被包含在了Wicket的应用逻辑里,从而极大地简化了配置。
七、Wicket1.2的RoadMap
* JavaScript support
* CSS support
* Markup inheritence
* Experimental AJAX support
* Improved URL handling
* Include of external markup
* Simplified Choice component
* Improved Feedback support
* Thread safe validation (bug fix)
* Immediate button support for Forms
* Panel support for TreeView
* Date picker component
* Component reference examples
* AJAX support
* Portlet support (JSR 168)
* Clean and pretty URL's
* JAAS/Acegi/other security integration
八、参考资料
http://wicket.sourceforge.net/
http://www.wicket-wiki.org.uk/wiki/index.php/Newuserguide
分享到:
相关推荐
Web框架对比: Wicket vs Struts
Java Web层框架之比较—比较JSF、Spring MVC、Stripes、Struts 2、Tapestry和Wicket.doc
Wicket,有一个优秀的Web框架。和Struts和Webwork类似的Java WEB开发框架。优点在于对HTML和业务代码进行了有效的分离(流行的WEB框架大多如此)。基于规则的配置(有效减少了XML配置文件的使用,与Spring相比,...
Wicket是一个基于Java的Web开发框架,与Struts,WebWork,Tapestry类似。其特点在于对Html和代码进行了有效的分离(有利于程序员和美工的合作),基于规则的配置(减少了XML等配置文件的使用),学习曲线较低(开发...
Wicket 是一个 Java 语言的 Web 开发框架,与 Struts,WebWork,Tapestry 相类似。 其特点在于对 Html 和代码进行了有效的分离(有利于程序员和美工的合作),基于规则的配置(减少了 XML 等配置文件的使用),学习...
面向组件的Web开发框架的优点 3.4。Wicket与其他面向组件的框架相比 威克特说“你好世界!” 4.1。Wicket分发和模块 4.2。Wicket应用程序的配置 4.3。HomePage类 4.4。Wicket链接 4.5。摘要 5. Wicket作为页面布局...
Wicket是什么 简单点说,它是一个基于JAVA的WEB开发框架,与Struts ,WebWork,Tapestry 相类似。其特点在于对Html 和代码进行了有效的分离(有利于程序员和美工 作),基于规则的配置 减少了XML等配置文件的使用 ...
去年就听说不少Web框架的开发人员要联合起来开一个Web框架,在Yahoo上还有一个讨论组,上去看了一下。但是这个事件对我的第一感觉就是晕,第二感觉就是特别的晕,虽然目前Java世界的Web框架一通混战,但这样一...
简单点说,它是一个基于Java 的Web开发框架,与Struts,WebWork, Tapestry相类似。其特点在于对Html 和代码进行了有效的分离(有利于程序员和美工的合 作),基于规则的配置 ( 减少了 XML 等配置文件的使用 ) ,...
简单点说,它就是一个基于Java 的Web 开发框架,与Struts,WebWork,Tapestry 相类似。其特点在于对Html 和代码进行了有效的分离(有利于程序员和美工的合作),基于规则的配置(减少了XML 等配置文件的使用),学习...
简单点说,它是一个基于Java 的Web 开发框架,与Struts,WebWork, Tapestry 相类似。其特点在于对Html 和代码进行了有效的分离(有利于程序员和美工的合 作),基于规则的配置(减少了XML 等配置文件的使用),学习...
简单点说,它就是一个基于Java 的Web 开发框架,与Struts, WebWork,Tapestry相类似。其特点在于对Html 和代码进行了有效的分离(有利于程序员 和美工的合作),基于规则的配置(减少了XML 等配置文件的使用)...
Java 的 Web框架虽然各不相同,但基本也都是遵循特定的路数的:使用Servlet或者Filter拦截请求,使用MVC的思想设计架构,使用约定,XML或 Annotation实现配置,运用Java面向对象的特点,面向抽象实现请求和响应的...
Shiro(Apache Shiro)是一个强大且易于使用的Java安全框架,用于身份验证、授权、...容器友好:Shiro可以与常见的Java容器(如Spring、Guice)以及其他框架(如Apache Struts、Apache Wicket)进行集成,方便开发者