struts详解.docVIP

Mvc 设计思想把一个web应用分成3个基本部分：Model（模型）；View（视图）和Controller（控制器），这3个部分相互之间耦合比较小，提高了程序的可扩展性，更适合于大型项目的开发。 对于Struts1框架来讲，控制器就是它的核心，由两部分组成：核心控制器和业务逻辑控制器。 用户发送的请求会被核心控制器拦截，核心控制器会将请求转发给对应的业务逻辑控制器，业务逻辑控制器调用模型层来处理用户的请求。 从流程图中，我们可以清楚的看到mvc中的3个角色 Model部分由底层的业务逻辑组件充当，这些业务逻辑组件封装了底层数据库的访问和业务逻辑的封装。 Struts1 并没有为model组件提供任何支持 Struts1 的view由jsp来完成，Struts提供了大量的标签，简化了jsp的编写。 Controller部分由两部分组成： 核心控制器 ： 由Struts框架提供，是一个servlet，负责拦截所有的用户请求，然后根据用户请求，来将请求转发给业务逻辑控制器。 业务逻辑控制器 ：我们自己写的Action，但是它本身并不具备处理的能力，需要调用Model部分来完成处理 对应任何mvc框架而言，其实只是实现了控制器部分，由控制器部分调用模型层，并完成模型与视图的整合。 Struts1自身的局限。 只支持jsp作为表现层技术，这是由于其出现的年代太早，那个时候还没有其它表现层技术 与servlet api严重耦合，难于测试，想想我们的Action 代码严重依赖于struts1 的API，属于侵入式设计。这种侵入式设计的最大弱点在于，一旦系统需要重构时，这些Action类将完全没有利用的价值，成为一堆废品。导致了 设计上的代码复用性很低。 Struts2并非全新的框架，源于opensymphony组织的webwork框架，而webwork框架源于xwork,。 Webwork 的设计理念和struts1 有着本质的区别： struts1 终究还是对servlet的封装; 而Webwork则充分体现了aop的设计思想，webwork的核心控制器调用的是代理对象，在创建代理对象时，根据用户提供的配置文件，以业务逻辑控制器为目标对象，拦截器为处理（Advice）webwork提供了系列拦截器，拦截器链自动对请求应用通用功能。 由于webwork出现的比较晚，所以应用不如struts1那样广泛， 这就造成了落后的技术反而流行的局面，于是struts社区和Webwork社区进行了合并，共同去维护struts2， struts2和struts1基本上没有任何血缘关系，webwork的最后一个版本修改包名后成为struts1的第一版本。 Struts2的下载地址是 解压后的目录包含4个文件夹 apps: 包含了一下Struts2的实例 docs: struts2的相关文档 lib: struts2的核心类库和所依赖的第三方类库 src: struts2的全部源码 在项目中使用struts2的步骤： 复制struts2必须的6个jar file: freemarker-x.jar，ognl-x.jar，struts2-core-x.jar，xwork-2.1.2.jar，commons-logging-x.jar，commons-fileupload-x.jar，commons-io-x.jar 修改web.xml文件，注册其核心控制器 filter filter-namestruts2/filter-name filter-class org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter /filter-class /filter filter-mapping filter-namestruts2/filter-name url-pattern/*/url-pattern /filter-mapping 编写自己的业务逻辑控制器, 普通pojo类即可，但要包含如下方法 public String execute() 在struts.xml配置业务逻辑控制器， Action 必须要配置在package中，package的概念跟程序中包的概念类似，主要有两项功能： 解决了命名冲突 Struts2的Action 和struts1的Action区别非常显著：struts2的Action非单例，每次用户请求到来以后都会产生一个新的实例，而struts1的Action 是单例的，在编写struts1的Action的时候务必要小心线程安全问题， 而struts2中该问题不复存在。 包的定义需要注意如下问题： 每个包都要有自