Web框架对比: Wicket vs Struts

转载 2015年11月21日 18:41:33
一、概貌

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

相关文章推荐

Wicket 框架初探

作者:David R. Heffelfinger  原文:http://ensode.net/wicket_first_look.html译者:Jason Ho 介绍 当 Kevin Taylor 询...
  • npstar
  • npstar
  • 2006年01月14日 21:52
  • 4541

Wicket与Struts两个框架比较

 Wicket与Struts两个框架比较document.title="Wicket与Struts两个框架比较 - "+document.title原作者:  Wicket团队原文地址:http://...
  • teddylu
  • teddylu
  • 2006年01月18日 09:49
  • 659

比较开源Java Web框架JSF、Spring MVC、Stripes、Struts2、Tapestry、Wicket

Matt通过采访这些框架的作者,与他们讨论各种开源的Java Web框架,并且突出各个框架的长处、听取框架作者对其他框架的看法,希望借此了解这些框架的未来发展方向。   下列是一些被采访者: ...
  • xy5811
  • xy5811
  • 2011年12月27日 11:34
  • 749

Java Web层框架——JSF、Spring MVC、Stripes、Struts 2、Tapestry和Wicket他们各自的优点和缺点

JSF   优点:   ◆Java EE标准,这意味着有很大的市场需求和更多的工作机会   ◆上手快速并且相对容易   ◆有大量可用的组件库   缺点:   ◆大量的JSP...

Java Web层框架比较—— 比较JSF、Spring MVC、Stripes、Struts 2、Tapestr和Wicket他们各自的优、缺点

【译者按】这是Matt Raible在今年6月24-27号召开的JA-SIG夏季会议上所作的主题演讲,Matt从众多方面对Java Web层框架做了一个全面、深入的比较。笔者认为这是一份及时的文档,它...

【第十章】集成其它Web框架 之 10.3 集成Struts2.x 集成JSF ——跟我学spring3

先进行通用配置, 【第十章】集成其它Web框架 之 10.1 概述    10.3  集成Struts2.x 10.3.1  概述 Struts2前身是WebWork,核心并没有改变,...

【第十章】集成其它Web框架 之 10.3 集成Struts2.x ——跟我学spring3

先进行通用配置, 【第十章】集成其它Web框架 之 10.1 概述    10.3  集成Struts2.x 10.3.1  概述 Struts2前身是WebWork,核心并没有改变,其实就是...
  • zhaoshe
  • zhaoshe
  • 2013年03月11日 09:21
  • 453

【第十章】集成其它Web框架 之 10.2 集成Struts1.x ——跟我学spring3

转自:http://sishuok.com/forum/blogPost/list/2511.html 10.2  集成Struts1.x 10.2.1  概述        Str...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Web框架对比: Wicket vs Struts
举报原因:
原因补充:

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