MVC框架 大PK

1，Struts1.x
所有客户端Http请求发送至Struts的核心控制器ActionServlet, 它会根据Struts-config.xml配置文件，找到相应的Action类。同时将请求参数封装到ActionForm。Action调用Model层的业务方法，根据结果，Action返回ActionForm对象。
--------------------------------------------------------------------

2，JSF
客户端通过事件触发，将请求通知给JSF的核心控制器FacesServlet， FacesServlet会创建一个FacesContext对象，它里面包含了处理请求所必须的信息，接着FacesServlet会将控制权交给LifeCycle处理器。
（LifeCycle生命周期）：
恢复视图 ----》 应用请求值 ----》处理验证 ----》更新模型值 ----》调用应用程序
----》 呈现响应
-------------------------------------------------------------------
3，SpringMVC
客户端发送请求到Spring的核心控制器DispacherServlet，它会根据配置文件
(xxx-servlet.xml)找到对应的处理器Handler
Handler处理完业务逻辑后将返回ModelAndView给DispatherServlet. ModelAndView包含了视图逻辑和渲染视图所需用到的模型数据对象，由于ModelAndView包含的是视图逻辑名，所以需通过ViewResolver来完成解析，最后DispatherServlet将请求分派给View对象。
------------------------------------------------------------------

4，WebWork
浏览器发送的请求都被ServletDispacher截获，ServletDispather根据服务名，解析对应的Action名。AppalicationContext，遍历HttpServletRequest，HttpSession，ServletContext中的数据，将其复制到WebWork的Map实现中，至此之后，数据操作在Map结构中进行，完成内部结构与ServletAPI的分离
ActionProxyFactory根据xwork配置文件（xwork.xml）创建ActionProxy实例，ActionProxy中包含Action的配置信息。
ActionProxy创建相应对应的Action实例，并根据配置进行一系列的处理程序，包含执行相应的预处理程序以及对Action运行结果进行处理。
-----------------------------------------------------------------

5，Struts2
a，浏览器发送请求，
b，核心控制器FilterDispather根据请求决定调用合适的Action
c，WebWork的拦截器链自动对请求应用通用功能，例如WorkFlow，Validation或文件上传等功能
d，回调Action的execute方法处理结果信息将被输出到浏览器中，可以是HTML页面，图像，也可以是PDF文档或者其他文档。此时支持的视图技术非常多，既支持JSP，也支持Velocity，FreeMarker等模板技术。
----------------------------------------------------------------


Struts1.x存在的问题？
1，支持的表示层技术单一
2，与ServletAPI严重耦合，难于测试。
3，代码严重依赖于Struts1API，属于侵入式设计
----------------------------------------------------------------

Struts2与Struts1的对比
1，在Action实现类方面：Struts1要求Action类继承一个抽象基类；Struts1的一个具体问题是使用抽象类编程而不是接口。Struts2 Action类可以实现一个Action接口，也可以实现其他接口，使可选和定制服务成为可能。 Struts2 提供一个ActionSupport基类 去实现常用的接口。即使Action接口不是必须实现的，只有一个包含execute方法的POJO类都可以用作Struts2的Action。
2，线程模式方面：Struts1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts1 Action能做的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的；Struts2 Action对象为每一个请求
产生一个实例，因此没有线程安全问题。

3，Servlet依赖方面：Struts1 Action依赖于Servlet API，因为Struts1 Action的execute方法中有HttpServletRequest和HttpServletResponse方法。Struts2 Action 不再依赖于ServletAPI，从而允许Action脱离Web容器运行，从而降低了测试Action的难度。当然，如果Action 需要直接访问HttpServletRequest和HttpServletResponse参数，Struts2 Action仍然可以访问它们。但是，大部分时候，Action都无需直接访问HttpServletRequest和HttpServletResponse，从而给开发者更多灵活的选择。

4，可测试方面：测试Struts1 Action的一个主要问题是execute方法依赖于Servlet于ServletAPI， 这使得Action 仍然的测试要依赖于Web容器。为了脱离Web容器测试Struts1 的Action， 必须借助于第三方扩展：Struts TestCase，该扩展下包含了系列的Mock对象，从而脱离Web容器测试Struts1的Action类。Struts2 Action可以通过初始化，设置属性，调用方法来测试。

5，封装请求参数方面：Struts1 使用ActionForm对象封装用户的请求参数，所有的ActionForm 必须继承一个基类：ActionForm。 普通的JavaBean不能用作ActionForm
因此，开发者必须创建大量的ActionForm类封装用户请求参数。虽然Struts1 提供了动态ActionForm 来简化 ActionForm 的开发，但依然需要在配置文件中定义ActionForm； Struts2 直接使用Action 属性来封装用户请求属性，避免了开发者需要大量开发ActionForm类的繁琐，实际上，这些属性还可以是包含子属性的Rich对象类型。如果开发者依然怀念Struts1 ActionForm 的模式，Struts 2 提供了ModelDriven 模式， 可以让开发者使用单独的Model 对象来封装用户请求参数，但该Model对象无须继承任何Struts2基类，是一个POJO，从而降低了代码污染。

6，表达式语言方面：Struts1 整合了JSTL，因此可以使用JSTL表达式语言。这种表达式语言有基本对象图遍历，但在对集合和索引属性的支持上则功能不强；Struts2 可以是用JSTL，但它整合了一种更强大和灵活的表达式语言：OGNL（Object Graph Notation Language）,因此，Struts2下的表达式语言功能更加强大。

7，绑定值到视图方面：Struts1 使用标准JSP机制把对象绑定到视图页面；Struts2 使用“ValueStack”技术，使标签能够访问值，而不需要把对象和视图页面绑定在一起。

8，类型转换的方面：Struts 1 ActionForm 属性通常都是String 类型。 Struts1 使用
Commons-Beanutils 进行类型转换，支持基本数据类型和常用对象之间的转换。

9，数据校验的方面：Struts1 支持在ActionForm 重写 validate方法手动校验，或者通过整合Commons alidator框架来完成数据校验。Struts2 支持通过重写validator方法进行校验，也支持整合XWork校验框架进行校验

10，Action执行控制的方面：Struts1 支持每一个模块对应一个请求处理（既生命周期的概念），但是模块中的所有Action必须共享相同的生命周期。Struts2支持通过拦截器堆栈为每一个Action 创建不通的生命周期。开发者可以根据需要创建相应堆找，从而和不同的Action一起使用。

-----------------------------------------------------------------------------------
WebWork 和 Struts2对比
从某种程度上来看，Struts2是WebWork的升级，而不是Struts1的升级，甚至在Apache的Struts2的官方文档都提到：WebWork到Struts2是一次平滑的过渡。实际上，Struts2 其实是WebWork2.3而已，从WebWork2.3 迁移到Struts2.0 不会比WebWork2.1到2.2更麻烦。
在很多方面，Struts2 仅仅是改变了WebWork 下的名称，因此，如果开发者具有WebWork 的开发经验，将可以更加迅速地进行Struts2的开发领域。
另外，Struts2 删除了WebWork中少量的特性。

评论

9 楼 fujohnwang 2009-03-18  

timerri 写道

从架构上来说，继承于servlet的框架大部分走的还是servlet架构的老路，最多就是多进行了几次重定向和数据映射。架构上没有任何的超越。而繁多的框架又吸引了太多人的目光，这真可谓是java界的悲哀。事实上，能掌握servlet，就基本能掌握所有这些框架了。

为什么很少人能从架构上做文章呢？简单举个例子，request进来后不再进入线程池，而是进入request队列并分解到对应的controler队列，每个controler独立且仅维护自己的线程（或用背对背的方式多controler共用一个线程），并仅从自己的队列读取request处理后将返回结果添加到response队列（response队列也可级联），最后由server读取response队列并返回。这种就是纯粹的异步操作，在高并发下会有远远超越现有架构的能力。一些应用服务器已经有了这样的苗头，可惜，为了servlet架构，还是继续在使用线程池。java这么多技术里，就spring还有些新意，可惜还是经常被滥用。

不好意思，借你的地方抱怨了一下，现在越来越觉得上javaeye是在浪费时间。除了个别人外。很少有人能够直指本质的讨论问题。就算讨论了，也没几个人能听懂。

我还是继续研究我的嵌入式去吧....

refer to EDA - SEDA

just an alternative to threading model.

8 楼 kimmking 2009-02-27  

lz虽然分析的不深，但是也不错~~


k可惜了，此贴进了新手区~~

java区那么多该进的都没进~~

哎~

7 楼 zjit 2009-02-26  

timerri 写道

从架构上来说，继承于servlet的框架大部分走的还是servlet架构的老路，最多就是多进行了几次重定向和数据映射。架构上没有任何的超越。而繁多的框架又吸引了太多人的目光，这真可谓是java界的悲哀。事实上，能掌握servlet，就基本能掌握所有这些框架了。

为什么很少人能从架构上做文章呢？简单举个例子，request进来后不再进入线程池，而是进入request队列并分解到对应的controler队列，每个controler独立且仅维护自己的线程（或用背对背的方式多controler共用一个线程），并仅从自己的队列读取request处理后将返回结果添加到response队列（response队列也可级联），最后由server读取response队列并返回。这种就是纯粹的异步操作，在高并发下会有远远超越现有架构的能力。一些应用服务器已经有了这样的苗头，可惜，为了servlet架构，还是继续在使用线程池。java这么多技术里，就spring还有些新意，可惜还是经常被滥用。

不好意思，借你的地方抱怨了一下，现在越来越觉得上javaeye是在浪费时间。除了个别人外。很少有人能够直指本质的讨论问题。就算讨论了，也没几个人能听懂。

我还是继续研究我的嵌入式去吧....

哥们，没事，你的“抱怨” 我 觉得是有那么点道理的
MVC框架整了这么多年，还是一个模式
核心控制器，资源配置文件，参数封装，线程池...
我觉得如果没有新意没有创新，那么请别胡乱弄个什么新名词什么新框架忽悠我们程序员

6 楼 wolfbrood 2009-02-26  

<div class="quote_title">timerri 写道</div>
<div class="quote_div">从架构上来说，继承于servlet的框架大部分走的还是servlet架构的老路，最多就是多进行了几次重定向和数据映射。架构上没有任何的超越。而繁多的框架又吸引了太多人的目光，这真可谓是java界的悲哀。事实上，能掌握servlet，就基本能掌握所有这些框架了。<br /><br />为什么很少人能从架构上做文章呢？简单举个例子，request进来后不再进入线程池，而是进入request队列并分解到对应的controler队列，每个controler独立且仅维护自己的线程（或用背对背的方式多controler共用一个线程），并仅从自己的队列读取request处理后将返回结果添加到response队列（response队列也可级联），最后由server读取response队列并返回。这种就是纯粹的异步操作，在高并发下会有远远超越现有架构的能力。一些应用服务器已经有了这样的苗头，可惜，为了servlet架构，还是继续在使用线程池。java这么多技术里，就spring还有些新意，可惜还是经常被滥用。<br /><br />不好意思，借你的地方抱怨了一下，现在越来越觉得上javaeye是在浪费时间。除了个别人外。很少有人能够直指本质的讨论问题。就算讨论了，也没几个人能听懂。<br /><br />我还是继续研究我的嵌入式去吧....</div>
<p> </p>
<p>比较有个性的人，不错</p>

5 楼 天机老人 2009-02-25  

呵呵spring mvc 也可以使用 ongl 而且可以实现pojo的form！
现在开发感觉比较轻还不错！

4 楼 timerri 2009-02-25  

从架构上来说，继承于servlet的框架大部分走的还是servlet架构的老路，最多就是多进行了几次重定向和数据映射。架构上没有任何的超越。而繁多的框架又吸引了太多人的目光，这真可谓是java界的悲哀。事实上，能掌握servlet，就基本能掌握所有这些框架了。

为什么很少人能从架构上做文章呢？简单举个例子，request进来后不再进入线程池，而是进入request队列并分解到对应的controler队列，每个controler独立且仅维护自己的线程（或用背对背的方式多controler共用一个线程），并仅从自己的队列读取request处理后将返回结果添加到response队列（response队列也可级联），最后由server读取response队列并返回。这种就是纯粹的异步操作，在高并发下会有远远超越现有架构的能力。一些应用服务器已经有了这样的苗头，可惜，为了servlet架构，还是继续在使用线程池。java这么多技术里，就spring还有些新意，可惜还是经常被滥用。

不好意思，借你的地方抱怨了一下，现在越来越觉得上javaeye是在浪费时间。除了个别人外。很少有人能够直指本质的讨论问题。就算讨论了，也没几个人能听懂。

我还是继续研究我的嵌入式去吧....

3 楼 netfishx 2009-02-25  

月经贴。。。。。。

2 楼 wintersun 2009-02-22  

引用

如果开发者依然怀念Struts1 ActionForm 的模式，Struts 2 提供了ModelDriven 模式

我想应该没有人会怀念吧，呵呵

1 楼 yyjn12 2009-02-22  

优点都是什么呢？