Question

struts2比Strust1有什么优势

Answer 1

struts1
2001年6月发布struts1
struts1的核心是控制器，由两部分组成：核心控制器和业务逻辑控制器，核心控制器是ActionServlet，由struts1提供；业务逻辑控制是用户自定义的action，由应用开发者提供。
整个应用由客户端请求驱动，客户端向web发送的请求被struts1的核心控制器ActionServlet拦截，ActionServlet根据请求决定是否调用业务逻辑控制器处理用户请求（事实上，业务逻辑控制器还是控制器，它只是负责调用模型来处理用户请求），当用户请求处理完后，其处理结果通过jsp呈现给用户。
如果用户只是希望得到某个url资源，得有ActionServlet将被请求的资源转发给用户。

struts1中的mvc：
1）struts1的model部分主要由底层的业务逻辑组件充当，这些业务逻辑组件封装了底层数据库访问、业务逻辑方法实现。对于一个成熟的企业应用而言，model部分不是一个简单的javabean所能完成的。总之，model部分封装了整个应用的所有业务逻辑，但整个部分并不是struts1提供的，struts1也没有为实现model组件提供任何支持。
2）struts1的view部分采用jsp实现。提供了标签库，能减少脚本的使用。标签库可以输出控制器的处理结果。
但struts1锁支持的表现层技术非常单一：既不支持FreeMarker、Velocity等模版技术，也不支持JasperReports等报表技术
3）struts1的核心控制器ActionServlet继承HttpServlet类，因此可配置为标准的servlet，负责拦截所有的http请求
业务逻辑控制器负责处理用户请求，但其自身并不具有处理能力，而是调用model来处理请求
不得不佩服struts1设计者高度解耦的设计：控制器并没有直接转发请求，而仅仅返回一个ActionForward对象（可理解为逻辑视图名）--实际的转发放在配置文件struts-config.xml中进行管理，配置文件中定义了逻辑视图名与视图资源之间的对应关系。当ActionServlet得到处理器返回的ActionForward对象后，根据对应关系，将视图资源呈现给用户。

struts1的种种缺陷：
1）支持的表现层技术单一
struts1只支持jsp作为表现层技术，不提供表现层技术的整合。出现年代太早，当时还没有出现FreeMarker、Velocity等技术
2）与servlet API严重耦合，难于测试
因为struts1是在model2的基础上发展起来的，因此它完全是基于Servlet API的，所以在struts1的业务逻辑控制器内，充满了大量的servlet API
action中的参数，通常web容器负责初始化，HttpServletRequest和HttpServletResponse都是servlet API，严重依赖web服务器，因此，一旦脱离web容器，测试action非常困难。
Action代码片段：
Java代码
//业务逻辑控制器必须继承struts1的Action类
public class LoginAction extends Action
{
//处理用户请求的execute方法
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)throws
AuctionException
{
//获取封装用户请求参数的ActionForm对象
//将其强制转换为登陆用的ActionForm
LoginForm loginForm = (LoginForm)form;
//当用户名为scott,密码为tiger时，返回成功
if ("scott".equals(loginForm.getUsername()
&& "tiger".equals(loginForm.getPassword())
{
//处理成功，返回一个ActionForward对象
return mapping.findForward("success");
}
else
{
//处理失败，返回一个ActionForward对象
return mapping.findForward("false");
}
}
}

3）代码严重依赖struts1 API，属于侵入式设计
struts1的action类必须继承struts1的action基类，实现处理方法时，又包含了大量的struts1 API：ActionMapping、ActionForm、ActionForward。
这种侵入式设计的最大弱点在于，一旦系统需要重构，这些action类将完全没有利用价值，成为废品。
可见，struts1的action类的这种侵入式设计 导致了较低的代码复用。

struts2
2006年

struts2的大致处理流程如下：
1）浏览器发送请求，例如请求/mypage.action、/reports/myreport.pdf
2）核心控制器FilterDispatcher根据请求决定调用合适的Action
3）webwork的拦截器链自动对请求应用通用功能，例如：workfolw、validation或文件上传等功能
4）回调Action的execute方法，该execute方法先获取用户请求参数。实际上，因为Action只是一个控制器，它会调用业务逻辑组件来处理用户的请求
5）Action的execute方法处理结果信息将被输出到浏览器中，此时支持的视图技术非常多。

struts2的配置文件有两份：
1）配置Action的struts.xml文件
2）配置struts2全局属性的struts.properties
定义action的处理结果时，可以指定多个result，result元素指定execute方法返回值和试图资源之间的映射关系。
<result name="cancel" type="redirect-action">Welcome</result>
定义result元素时，可以指定两个属性：type和name，其中name指定execute方法返回的字符串，type指定转向的资源类型，可以是jsp，也可以是freemarker等，甚至是另一个action，这也是struts2可以支持多种视图技术的原因。

struts2的控制器组件：
所有的MVC框架都是以控制器组件为核心，struts2的控制器有两部分组成：FilterDispatcher和业务控制器Action。
实际上，struts2中起作用的业务控制器不是用户定义的Action，而是系统生成的Action代理，但该Action代理以用户定义的Action为目标。
通过查看action代码发现，struts2的action比webwork的action更彻底，该action无需实现任何父接口，无需实现任何struts2基类，该action完全是一个POJO（普通、传统的java对象），具有很好的复用性。
归纳起来，struts2的action具有如下优势：
1）action类完全是一个pojo，因此具有很好的代码复用性；
2）action类无需与servlet API耦合，因此进行单元测试非常简单
3）action类的execute方法就仅返回一个字符串作为处理结果，该处理结果可映射到任何的结果，甚至是另一个action

-------------------------
struts1和struts2的简要对比：
1）action实现类方面的对比：struts1要求action类继承一个抽象基类，是使用抽象类编程而不是接口；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；struts2 action不在依赖于servlet api，从而允许action脱离web容器运行，降低测试难度。
4）可测性方面的对比：struts1 action的容器，脱离web容器测试struts1 action需要借助于第三方扩展 struts testcase；struts2 action可通过初始化，设置属性，调用方法来测试。
5）封装请求参数的对比
6）表达式语言方面的对比：struts1 整合了JSTL ，struts2也可以使用JSTL，而且整合了一种更强大和灵活的表达式语言：OGNL
7）绑定值到视图的对比：struts1使用标准JSP机制把对象绑定到视图页面；struts2使用“ValueStack”技术，使标签库能访问值，而不需要把对象和视图页面绑定到一起。
8）类型转换的对比：Stuts1的actionForm的属性通常都是String类型，struts1使用comments-beanutils进行类型转换，每个类一个转换器，转换器是不可配置的；struts2使用OGNL进行类型转换，支持基本数据类型和常用对象之间的转换。
9）数据校验对比：struts1支持在actionFrom重写validate方法中手动校验，或者通过整合Commons alidator框架来完成数据校验。struts2支持重写validate方法进行校验，也支持整合xwork校验框架进行校验。
10）action执行控制的对比：struts1支持为每个模块对应一个请求（即生命周期的概念），但模块中的所有action必须共享相同的生命周期。struts2支持通过连接器堆栈（Interceptor Stacks）为每个action创建不同的生命周期。

Answer 2

直接用没法兼容，建议最少用jdk1.5，直接用1.6不是更好么，而且tomcat 6.0都不支持jdk1.4了，如果非要使用1.4就参考下下面的文章：

Answer 3

其实无所谓优势与否，看公司的体系了。我门公司现在很多项目很是用的struts1，但并不是说struts2不好，可能是习惯吧！

Answer 4

我就简单谈谈的看法吧
1：struts1的核心是个servlet ,与servlet API严重耦合，难于测试，而且还是单例，就造成了一定的限制。资源必须为线程安全或者同步
而struts2的核心是个过滤器，为每一个请求实例化一个对象，所以没有线程安全的问题。
2：struts1的Action类依赖于servlet API 属于侵入式设计 。struts2的Action与容器无关
3：struts1整合Jstl标签，所以就使用JSTL表达语言。struts2使用JSTL，也支持更灵活的OGNL（对象图形符号语言）
4：struts1用ActionForm对象来获取输入，并且还有验证功能。
struts2 Action属性作为输入属性，就减少了第二个输入对象的需要