框架模型strutshibernate.docx
《框架模型strutshibernate.docx》由会员分享，可在线阅读，更多相关《框架模型strutshibernate.docx（37页珍藏版）》请在冰豆网上搜索。
框架模型strutshibernate
Struts2
目录
Struts2概述
Struts2工作原理
Struts技术的发展概况
Struts的体系结构
Struts2和Struts1的对比
WebWork和Struts2的对比
Struts2中的ActionSupport基类
展开
Struts2概述
Struts2工作原理
Struts技术的发展概况
Struts的体系结构
Struts2和Struts1的对比
WebWork和Struts2的对比
Struts2中的ActionSupport基类
展开
编辑本段Struts2概述
Struts2是Struts的下一代产品，是在struts1和WebWork的技术基础上进行了合并的全新的Struts2框架。
其全新的Struts2的体系结构与Struts1的体系结构差别巨大。
Struts2以WebWork为核心，采用拦截器的机制来处理用户的请求，这样的设计也使得业务逻辑控制器能够与ServletAPI完全脱离开，所以Struts2可以理解为WebWork的更新产品。
虽然从Struts1到Struts2有着太大的变化，但是相对于WebWork，Struts2的变化很小。
编辑本段Struts2工作原理
工作原理（2张）
编辑本段Struts技术的发展概况
经过六年多的发展，Struts1已经成为了一个高度成熟的框架，不管是稳定性还是可靠性都得到了广泛的证明。
市场占有率超过20%，拥有丰富的开发人群，几乎已经成为了事实上的工业标准。
但是随着时间的流逝，技术的进步，Struts1的局限性也越来越多地暴露出来，并且制约了Struts1的继续发展。
对于Struts1框架而言，由于与JSP/Servlet耦合非常紧密，因而导致了一些严重的问题。
首先，Struts1支持的表现层技术单一。
由于Struts1出现的年代比较早，那个时候没有FreeMarker、Velocity等技术，因此它不可能与这些视图层的模版技术进行整合。
其次，Struts1与ServletAPI的严重耦合，使应用难于测试。
最后，Struts1代码严重依赖于Struts1API，属于侵入性框架。
从目前的技术层面上看，出现了许多与Struts1竞争的视图层框架，比如JSF、Tapestry和SpringMVC等。
这些框架由于出现的年代比较近，应用了最新的设计理念，同时也从Struts1中吸取了经验，克服了很多不足。
这些框架的出现也促进了Struts的发展。
目前，Struts已经分化成了两个框架：
第一个是在传统的Struts1的基础上，融合了另外的一个优秀的Web框架WebWork的Struts2。
Struts2虽然是在Struts1的基础上发展起来的，但是实质上是以WebWork为核心的。
Struts2为传统的Struts1注入了WebWork的先进的设计理念，统一了Struts1和WebWork两个框架。
Struts1分化出来的另外一个框架是Shale。
这个框架远远超出了Struts1原有的设计思想，与原有的Struts1关联很少，使用了全新的设计思想。
Shale更像一个新的框架而不是Struts1的升级。
本文下面的内容将主要讨论Struts2。
编辑本段Struts的体系结构
Struts2应用流程注解
当Web容器收到请求（HttpServletRequest）它将请求传递给一个标准的的过滤链包括
流程
（ActionContextCleanUp）过滤器，然后进过Otherfilters（SiteMesh,etc）,
接下来需要调用FilterDispatcher核心控制器，然后它调用ActionMapper确定请求那个Action，ActionMapper返回一个收集Action详细信息的ActionMaping对象。
接下来FilterDispatcher将控制权委派给ActionProxy,ActionProxy调用配置管理器（ConfigurationManager）从配置文件中读取配置信息（struts.xml），然后创建ActionInvocation对象，ActionInvocation在调用Action之前会依次的调用所用配置拦截器（InterceptorN）一旦执行结果返回结果字符串ActionInvocation负责查找结果字符串对应的（Result）然后执行这个ResultResult会调用一些模版（JSP）
来呈现页面，之后拦截器（InterceptorN）会在被执行（顺序和Action执行之前相反）最后响应（HttpServletResponse）被返回在web.xml中配置的那些过滤器和（核心控制器）（FilterDispatcher）。
编辑本段Struts2和Struts1的对比
通过上面对Struts2体系结构的了解，我们发现Struts2对Struts1进行了巨大的改进。
主要表现在如下几个方面：
在Action的实现方面：
Struts1要求必须统一扩展自Action类，而Struts2中可以是一个普通的POJO。
线程模型方面：
Struts1的Action工作在单例模式，一个Action的实例处理所有的请求。
Struts2的Action是一个请求对应一个实例（每次请求时都新new出一个对象）。
没有线程安全方面的问题。
Servlet依赖方面：
Struts1的Action依赖于ServletAPI，比如Action的execute方法的参数就包括request和response对象。
这使程序难于测试。
Struts2中的Action不再依赖于ServletAPI，有利于测试，并且实现TDD。
封装请求参数：
Struts1中强制使用ActionForm对象封装请求的参数。
Struts2可以选择使用POJO类来封装请求的参数，或者直接使用Action的属性。
表达式语言方面：
Struts1中整合了EL，但是EL对集合和索引的支持不强，Struts2整合了OGNL（ObjectGraphNavigationLanguage）。
绑定值到视图技术：
Struts1使用标准的JSP，Struts2使用“ValueStack”技术。
类型转换：
Struts1中的ActionForm基本使用String类型的属性。
Struts2中使用OGNL进行转换，可以更方便的使用。
数据校验：
Struts1中支持覆盖validate方法或者使用Validator框架。
Struts2支持重写validate方法或者使用XWork的验证框架。
Action执行控制的对比：
Struts1支持每一个模块对应一个请求处理，但是模块中的所有Action必须共享相同的生命周期。
Struts2支持通过拦截器堆栈为每一个Action创建不同的生命周期。
编辑本段WebWork和Struts2的对比
Struts和Webwork同为服务于Web的一种MVC框架，从某种程度上看，Struts2是从WebWork2上升级得到的。
甚至Apache的官方文档也讲：
WebWork2到Struts2是平滑的过渡。
我们甚至也可以说Struts2就是WebWork2.3而已。
在很多方面Struts仅仅是改变了WebWork下的名称。
Struts2对应的有自己的标签，并且功能强大。
Webwork也有自己的标签。
在2005年12月，WebWork与StrutsTi决定合并，再此同时，StrutsTi改名为StrutsActionFramework2.0,成为Struts真正的下一代。
编辑本段Struts2中的ActionSupport基类
ActionSupport基类中定义的五个标准返回值
ActionSupport基类中定义了五个标准的返回值，当然我们可以自己随意定义返回的名字
StringSUCCESS="success";//默认是SUCCESS类型
StringNONE="none";
StringERROR="error";
StringINPUT="input";
StringLOGIN="login";
ActionSupport基类中的方法
ActionSupport基类定义了了一些方法，程序员自己写的action如果继承了ActionSupport基类，就可以应用这些方法，很方便解决一些问题。
一些比较常用的方法：
getText（StringaTextName）;//国际化用到
...//getText（StringaTextName）的重载方法
addActionMessage（StringaMessage）;
addFieldError（StringfieldName,StringerrorMessage）;
//校验失败后返回给客户端的信息，struts2标签fielderror/>可以取得
addActionError（StringanErrorMessage）;
编辑本段ResultType
在默认时，标签的type属性值是“dispatcher”（实际上就是转发，forward）。
开发人员可以根据自己的需要指定不同的类型，如redirect、stream等。
如下面代码所示：
/result.jsp
这此result-type可以在struts2-core-2.0.11.1.jar包或struts2源代码中的struts-default.xml文件中找到，在这个文件中找到标签，所有的result-type都在里面定义了。
代码如下：
--DeprecatednameformscheduledforremovalinStruts2.1.0.ThecamelCaseversionsarepreferred.Seeww-1707-->
dispatcher
用来转向页面，通常处理JSP
org.apache.struts2.dispatcher.ServletDispatcherResult
freemaker
处理FreeMarker模板
org.apache.struts2.views.freemarker.FreemarkerResult
httpheader
控制特殊HTTP行为的结果类型
org.apache.struts2.dispatcher.HttpHeaderResult
stream
向浏览器发送InputStream对象，通常用来处理文件下载，还可用于返回AJAX数据
org.apache.struts2.dispatcher.StreamResult
StreamResult等价于在Servlet中直接输出Stream流。
这种Result被经常使用于输出图片、文档等二进制流到客户端。
通过使用StreamResult，我们只需要在Action中准备好需要输出的InputStream即可。
配置：
image/jpeg
imageStream
filename="document.pdf"
1024
同时，StreamResult支持许多参数，对输出的Stream流进行参数控制。
velocity
处理Velocity模板
org.apache.struts2.dispatcher.VelocityResult
随着模板技术的越来越流行，使用Freemarker或者Velocity模板进行View层展示的开发者越来越多。
Struts2同样为模板作为Result做出了支持。
由于模板的显示需要模板（Template）与数据（Model）的紧密配合，所以在Struts2中，这两个Result的主要工作是为模板准备数据。
xslt
处理XML/XLST模板
org.apache.struts2.views.xslt.XSLTResult
plainText
显示原始文件内容，例如文件源代码
org.apache.struts2.dispatcher.PlainTextResult
chain
用来处理Action链
com.opensymphony.xwork2.ActionChainResult
chain其实只是在一个action执行完毕之后，forward到另外一个action，所以他们之间是共享HttpServletRequest的。
在使用chain作为Result时，往往会配合使用ChainingInterceptor。
ChainingInterceptor的作用是在Action直接传递数据。
事实上，源Action中ValueStack的数据会被做一次Copy，这样，2个Action中的数据都在ValueStack中，使得对于前台来说，通过ValueStack来取数据，是透明而共享的。
比如说，一张页面中，你可能有许多数据要显示，而某些数据的获取方式可能被很多不同的页面共享（典型来说，“推荐文章”这个小栏目的数据获取，可能会被很多页面所共享）。
这种情况下，可以把这部分逻辑抽取到一个独立Action中，并使用chain，将这个Action与主Action串联起来。
这样，最后到达页面的时候，页面始终可以得到每个Action中的数据。
从实战上讲，使用chain作为Result也的确存在着上面所说的许多问题，我个人也是非常不推崇滥用这种Result。
尤其是，对于使用Spring和Hibernate的朋友来说，如果你开启OpenSessionInView模式，那么Hibernate的session是跟随HttpServletRequest的，所以session在整个action链中共享。
这会为我们的编程带来极大的麻烦。
因为我们知道Hibernate的session会保留一份一级缓存，在action链中，共享一级缓存无疑会为你的调试工作带来很大的不方便。
所以，谨慎使用chain作为你的Result，应该成为一条最佳实践。
redirect
重定向到一个URL
org.apache.struts2.dispatcher.ServletRedirectResult
如果你在Action执行完毕后，希望执行另一个Action，有2种方式可供选择。
一种是forward，另外一种是redirect。
有关forward和redirect的区别，这里我就不再展开，这应该属于Java程序员的基本知识。
在Struts2中，分别对应这两种方式的Result，就是chain和redirect。
先来谈谈redirect，既然是重定向，那么源地址与目标地址之间是2个不同的HttpServletRequest。
所以目标地址将无法通过ValueStack等Struts2的特性来获取源Action中的数据。
同时，Redirect的Result支持在配置文件中，读取并解析源Action中ValueStack的值，并成为参数传递到Redirect的地址中。
redirectAction
重定向到一个Action
org.apache.struts2.dispatcher.ServletActionRedirectResult
redirect-action
重定向到一个Action
org.apache.struts2.dispatcher.ServletActionRedirectResult
编辑本段区别
redirect和redirectActionchain的区别
struts2中关于result的返回类型一般我们是转发到一个jsp页面或者是html页面等，但是struts2中的result的返回类型还有redirect,redirectAction,chain。
对于这三种返回类型之间肯定是有区别的，下面我们来看看关于redirectredirectActionchain这三种struts2的返回类型之间的区别。
当使用type=“redirectAction”或type=“redirect”提交到一个action并且需要传递一个参数时。
这里是有区别的：
使用type=“redirectAction”时，结果就只能写Action的配置名，不能带有后缀：
“.action”
Xml代码
User?
u_id=${loginBean.u_id}
User?
u_id=${loginBean.u_id}
使用type=“redirect”时，结果应是action配置名+后缀名
Xml代码
User.action?
u_id=${loginBean.u_id}
redirect:
action处理完后重定向到一个视图资源（如：
jsp页面），请求参数全部丢失，action处理结果也全部丢失。
redirect-action:
action处理完后重定向到一个action，请求参数全部丢失，action处理结果也全部丢失。
chain:
action处理完后转发到一个action，请求参数全部丢失，action处理结果不会丢失。
mvc
百科名片
MVC三层架构
MVC是模型（Model）,视图（View）和控制（Controller）的缩写，其目的实现Web系统的职能分工。
其中Model层实现系统中的业务逻辑，通常可以用JavaBean或EJB来实现；View层用于与用户的交互，通常用JSP来实现；Controller层是Model与View之间沟通的桥梁，它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作。
∙ 查看精彩图册
外文名：
mvc
全名：
ModelViewController
产生时间：
1982年
架构内容：
视图，模型，控制器
类别：
一种设计模式
目录
简介
设计模式
设计模式
框架类别
优缺点
展开
简介
设计模式
设计模式
框架类别
优缺点
展开
编辑本段简介
MVC全名是ModelViewController，是模型（model）－视图（view）－控制器（controller）的缩写，一种软件设计典范，用于组织代码用一种业务逻辑和数据显示分离的方法，这个方法的假设前提是如果业务逻辑被聚集到一个部件里面，而且界面和用户围绕数据的交互能被改进和个性化定制而不需要重新编写业务逻辑MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
[1]
MVC开始是存在于Desktop程序中的，M是指数据模型
升级会员 