Wicket Struts 比较

 

转自http://tech.ccidnet.com/art/3737/20040114/448641_1.html

 

我的观点：

1，不赞成作者唯“面向对象”是对的观点，struts 遵循 http request-->response,这种模式，简明有什么不好的，为何非要为了概念而概念呢？

2，可能是我比较排斥新事物的原因作怪吧，毕竟要付出学习代价的。工作中用到了这个wicket给我带来了不便。

 

 

 

 

提纲

1 Wicket与Struts两个框架比较 1.1 概述 1.2 设计逻辑 1.3 处理HTTP请求 1.4 Servlet API & HTTP Protocol 的封装 1.5 状态管理 1.6 可配置性

Wicket与Struts两个框架比较

概述

Wicket是一个基于组件开发的Web程序框架. 其基本优点列表如下:

• 将 HTML与Java 两个开发时的关注点进行分离，有益于程序员与美工的合作开发
• 模型的设计基于面向对象 
• 自动管理对象的状态
• 极高的开发效率 
• 学习曲线很低
• 通过抽象，封装了Servlet API,HTTP protocol的相关细节
• 基于规则进行配置，不再需要XML文件进行配置
• 很容易开发可重用组件

Struts是一个基于MVC Model2模型的Web程序框架。其基本机制在于通过Action类来处理HTTP请求。通过XML文件进行配置。Struts通常与其它技术（经常为JSP和定制Tag库）联合使用。接下来这篇文章主要描述这两个框架间的区别，并进一步说明Wicket比Struts更优秀的原因（个人观点）。

设计逻辑 

Struts其设计方式在于将每一个HTTP请求转化成一个对指定Web程序特定类的请求。每一个Action类都将返回一个结果，该结果将包含下一步流程的相关信息。该结果把请求转到另外一个Action进行处理或者是将请求转给一个JSP页面，最终产生HTML页面反馈给用户。这种方法已经有点不合时适了，原因详列如下：

• 其设计并不基于面向对象的设计，诚然，每一个Action类都是一个抽象的体现，但该抽象更多的时候是由HTTP协议的机制来决定，而并不是基于面象对象的分析。
• 除非你想体验在java代码中输出HTML页面的痛苦，否则你仍然需要了解许多重要技术（包括JSP及定制Tag库）来输出HTML。使用Tag编写的JSP页面因为难以编辑和维护而饱受批评,对于习惯使用可视化开发的人员，这简直不可原谅.

Wicket的方式则完全不同。它完全基于面向对象，和基于组件设计，与Swing相类似。每一个Wicket页面都由许多控件组合而成（设计方式可以参考Composite模式）。借助标记文件（译注：通常为HTML文件），页面和控件负责输出（可以是HTML,译注：也可能是Swing的输出）。当发出HTTP请求后，系统会将相关信息转化成事件，进而将该事件交给相应的Component进行事件触发。所以Wicket解决了Struts设计上的两个问题:

• Wicket完全基于面向对象设计，你可以借助基于控件的继承来设计你的程序。你不要因为要配合 HTPP请求<-->回复这种机制来改变你的OO设计。
• Wicket使用几乎是纯粹的HTML作为标记文件，而且不需要引入额外的内容，与XHTML标准完全兼容（可能要使用Wicket的namespace）。懂HTML就可以编写Wicket的标记文件，即使不懂HTML的人员也可以借助各种工具来编写文件。

处理HTTP请求

在Struts中，当系统收到一个HTTP请求时，就会根据请求所访问的路径在配置文件中查找所映射的Action类。如果配置中指定的ActionForm Bean以及验证要求，系统也会根据请求参数调整Bean的属性并进行验证,（译注：这里指的应该是自动调用Validate方法）。 HTTP请求及回复以及ActionForm都将作为参数传递给Action进行处理。因此从这点上来分析，开发者得用Action对系统进行全面的控制。因此程序员必须手工处理HTTP session信息，并在HTTP请求及回复中控制各种属性。 请求结束时，Action必须返回一个相应的ActionForward以便让Struts框架知道如何进行下一步工作。如果ActionForward要转向JSP页面，程序员还必须编写JSP页面，可能还要使用各种标签库。这是一个费时费力的工作，因为程序员要管理XML配置文件，Java Action类以及定制Tag，不仅容易出错而且降低开发效率。

在Wicket中，当系统收到一个HTTP请求时，Wicket就会根据请求中的信息，找到相应的页面。如果这个请求是通过Form进行提交的，Wicket将会自动抽取参数，并进行验证，然后依照顺序将参数转化成相应的类型，并放入Model中。Wicket将请求转化成各种事件类型，然后以Listener的方式来调用相应的控件,程序员可以在事件代码中代理业务逻辑代码，并设置回复页面。Page类是通过反射进行调用并输出的。render的步骤依次查看页面上每一个控件，并由每个控件来输出自己。每一个控件可以在代码中输出HTML，也可以使用HTML标记文件来输出HTML。在控件与HTML绑定时，唯一要做的就是保证HTML元素属性中的命名（如 wicket:id="id1"，译注：目前可以通过命名空间来换成其它方式，如id="wicket-id1"）与控件名称相对应。（译注：如果有一个控件的名称为id1，this.add(new Label("id1","Hello"))，在HTML页面中应该有一个元素如下 <span wicket:id="id1"></span>，Wicket会自动将其换成 <span wicket:id="id1">Hello</span>）

Wicket框架功能更强的原因如下:

• 每一个Wicket控件都知道如何处理自己事件。因此，一旦你写了一个控件并放置在页面上，并编写了相关事件处理代码，该代码就会自动被Wicket调用。一个页面有超过20个控件，如果在最复杂的情况下，程序员需要编写20个事件处理代码。如果使用Strust，你可能要写20个不同的Action类，或者使用if/else语句进行逻辑转向处理，这种情况下的XML配置文件难以维护（译注：如果一定要用Struts的话，可以使用DispatchAction简化开发工作）。
• Wicket使你开发时，完全基于可重用控件及相关事件，你不要因为要配合 HTPP请求<-->回复这种机制来改变你的OO设计。
• 使用Wicket，代码的编写量要少很多，比Struts要少得多（译注：不完全这么认为，毕竟系统中业务代码占的比重很大）。因为可复用控件可以在内部包含更多的逻辑代码。利用Wicket标签结合HTML文件要比JSP+Tag要小的多，也不再需要额外的XML配置文件。

如果你曾经使用过Windows的API编写过程序，或者使用过Visual Basic或者Delphi，要接下的比较有益于你了解Wicket。编写Struts程序就象使用Windows的API一样：接收原始信息，解析该信息并进行处理。 （译注：这里忽略了一句话，因为觉得没有意义） Windows的API基于过程而且利用消息循环进行处理。

另一方面，Delphi就将Widnow的消息循环封装在一个TApplication类中,结合其它的类进行开发工作。Delphi的系统类（译注：原文为build-in，个人认为是Delphi提供的一些类），通过解析原始消息，并反馈信息的确认。接下来信息就会被转化成一个事件并发送给合适的对外。

与Windows程序相似, Wicket程序也有资源文件，使用property文件保存文本信息，使用HTML模板描述GUI，所以使用Wicket开发Web程序，就和使用Delphi开发桌面程序一样。

Servlet API & HTTP Protocol 的封装

Struts并没有封装Servlet API及HTTP协议的细节，使用Struts必须熟悉使用HttpServletRequest对象, 在Struts中HttpServletResponse和HttpSession类与Action, ActionForm, ActionMapping,ActionForward类一样重要。你开发Struts程序时，必须是基于请求<-->回复的HTTP协议。这也是所有基于Model2 MVC WEB开发框架的内存弱点。

而Wicket封装了Servlet API及HTTP协议的细节。对于大部分的程序，开发人员并不需要了解这些细节（译注：就我个人观点而言，这个说法有点问题，对于大部分程序的开发，只有小部分开发人员和小部分开发内容需要了解个别细节内容，如Session等信息，好象WicketSession有点问题）。即使对于非常复杂的程序，你也只是偶尔需要了解一下Wicket对协议的抽象类。使用Wicket开发，开发人员只需要使用Java控件类,POJO，一些基于POJO设计的业务模型，以及HTML标记页面文件。

状态管理

在大部分情况下，Struts需要开发人员自行对状态进行管理。如果开发的是个大规模，具有高伸缩性，需要集群支持程序，自然是很好。因为你需要对HttpSession进行各种粒度的控制。但是对于中小粒度的程序，这也意味着你需要做许多额外的代码，自然也费时费力。

Wicket的处理方式与此不。 默认情况下，Wicket通过缓存页面的控件类来处理了大部分状态管理。对于中小粒度的程序，几乎就不用写什么代码。但Wicket也公开了大量的API，允许程序员用自己的试来控制状态。对于大程序而言，对状态的自行控制仍然需要人工处理（译注：因为Wicket把大量信息放在HttpSession中，如果支持集群，大量的session信息需要在机器之间传递，很消耗资源）。 对于小程序，就不必人工处理了。事实上，即使写一个大规模程序，也可以先让Wicket管理程序的状态，在进行系统调优时，才使用定制的状态管理，以便进行优化。

可配置性

Strust需要一个XML文件来定义请求以及响应间的映射关系,还包括所有的ActionForm对象的定义。随着系统规模的增加，文件也会变成一个庞然大物，甚至复杂到难以维护。新版的Struts允许将使用多个配置文件来描述配置。这样尽管将配置文件的规模分解了，但XML文件的复杂度并没有因此减少。

Wicket没有配置文件（译注：只是Wicket默认的机制不需要，但开发人员仍然可以根据实际情况进行处理）. Wicket提供了一个配置类，可以利用反射调用默认构造函数进行配置，另外一般还提供了参数配置构造函数，参数由Servlet初始化参数。所有的HTTP请求的细节都被映射到控件的事件上，由控件根据Wicket逻辑输出相应的HTML代码。大部分情况下，Wicket应用程序只需要通过编写Web.xml文件即可解决配置问题，其它的配置文件不再需要了。