Java的strutsspringhibernate精通SSH三大框架的底层机制及原理.docx
- 文档编号:16519460
- 上传时间:2023-07-14
- 格式:DOCX
- 页数:23
- 大小:109.61KB
Java的strutsspringhibernate精通SSH三大框架的底层机制及原理.docx
《Java的strutsspringhibernate精通SSH三大框架的底层机制及原理.docx》由会员分享,可在线阅读,更多相关《Java的strutsspringhibernate精通SSH三大框架的底层机制及原理.docx(23页珍藏版)》请在冰点文库上搜索。
Java的strutsspringhibernate精通SSH三大框架的底层机制及原理
Struts1的工作原理
Struts1工作原理图:
1、初始化:
struts框架的总控制器ActionServlet是一个Servlet,它在web.xml中配置成自动启动的Servlet,在启动时总控制器会读取配置文件(struts-config.xml)的配置信息,为struts中不同的模块初始化相应的对象。
(面向对象思想)
2、发送请求:
用户提交表单或通过URL向WEB服务器提交请求,请求的数据用HTTP协议传给web服务器。
3、form填充:
struts的总控制器ActionServlet在用户提交请求时将数据放到对应的form对象中的成员变量中。
4、派发请求:
控制器根据配置信息对象ActionConfig将请求派发到具体的Action,对应的formBean一并传给这个Action中的excute()方法。
5、处理业务:
Action一般只包含一个excute()方法,它负责执行相应的业务逻辑(调用其它的业务模块)完毕后返回一个ActionForward对象。
服务器通过ActionForward对象进行转发工作。
6、返回响应:
Action将业务处理的不同结果返回一个目标响应对象给总控制器。
7、查找响应:
总控制器根据Action处理业务返回的目标响应对象,找到对应的资源对象,一般情况下为jsp页面。
8、响应用户:
目标响应对象将结果传递给资源对象,将结果展现给用户。
ssh框架启动流程
系统从职责上分为四层:
表示层、业务逻辑层、数据持久层和域模块层。
其中使用Struts作为系统的整体基础架构,负责MVC的分离,在Struts框架的模型部分,利用Hibernate框架对持久层提供支持,业务层用Spring支持。
具体做法是:
用面向对象的分析方法根据需求提出一些模型,将这些模型实现为基本的Java对象,然后编写基本的DAO接口,并给出Hibernate的DAO实现,采用Hibernate架构实现的DAO类来实现Java类与数据库之间的转换和访问,最后由Spring完成业务逻辑。
系统的基本业务流程是:
在表示层中,首先通过JSP页面实现交互界面,负责传送请求(Request)和接收响应(Response),然后Struts根据配置文件(struts-config.xml)将ActionServlet接收到的Request委派给相应的Action处理。
在业务层中,管理服务组件的SpringIoC容器负责向Action提供业务模型(Model)组件和该组件的协作对象数据处理(DAO)组件完成业务逻辑,并提供事务处理、缓冲池等容器组件以提升系统性能和保证数据的完整性。
而在持久层中,则依赖于Hibernate的对象化映射和数据库交互,处理DAO组件请求的数据,并返回处理结果。
采用上述开发模型,不仅实现了视图、控制器与模型的彻底分离,而且还实现了业务逻辑层与持久层的分离。
这样无论前端如何变化,模型层只需很少的改动,并且数据库的变化也不会对前端有所影响,大大提高了系统的可复用性。
而且由于不同层之间耦合度小,有利于团队成员并行工作,大大提高了开发效率。
Struts1与struts2有什么不同
1.Action类
Stuts1要求Action类继承一个抽象基类。
Struts1的一个普通问题是使用抽象类编程而不是接口。
Struts2Action类可以实现一个Action接口,也可以实现其它接口,使可选和定制的服务成为可能。
Struts2提供一个ActionSupport基类去实现常用的接口。
Action接口不是必须的,任何有execute标识的POJO对象都可以用作Struts2的Action对象。
2.线程模式:
Struts1Action是单例模式并且必须是线程安全的,因为仅有Action的一个实例来处理所有的请求。
单例策略限制了Struts1Action能作的事,并且要在开发时特别小心。
Action资源必须是线程安全的或同步的。
Struts2Action对象为每一个请求产生一个实例,因此没有线程安全问题。
3.Servlet依赖:
Struts1Action依赖于ServletAPI,因为当一个Action被调用时,HttpServletResquest和HttpServletResponse被传递给execute方法,即Action依赖了容器,测试变得非常麻烦。
Struts2Action不依赖于容器,允许Action脱离容器单独被测试。
如果需要,Struts2Action仍然可以访问初始的request和response。
但是,其它的元素减少或者消除了直接访问HttpServletRequset和HttpServletResponse的必要性。
4.捕获输入:
Struts1使用ActionForm对象捕获输入。
所有的ActionForm必须继承一个基类。
因为其它JavaBean不能用作ActionForm,开发者经常创建多余的类捕获输入。
动态Bean可以作为创建传统ActionForm的选择,但是,开发者可能是在重新描述已经存在的JavaBean,仍然会导致有冗余的javabean。
Struts2直接使用Action属性作为输入属性,消除了对第二输入对象的需求。
Action属性能够通过web页面上的taglibs访问。
Struts2也支持ActionForm模式。
(Struts2用普通的POJO来接收数据)
5.表达式语言:
Struts1整合了JSTL,但对集合和索引属性的支持很弱。
Struts2可以是使用JSTL,但是也支持一个更加强大和灵活的表达式语言“ObjectGraphNotationLanguage”(OGNL).
6.绑定值到页面(view):
Struts1使用标准JSP机制把对象绑定到页面中来访问,Struts1要传递值的时候必须往request里放、往session里放,然后再传递到jsp里面,铜鼓el表达式得到。
Struts2使用“ValueStack”技术,使taglib能够访问值而不需要把你的页面和对象绑定起来。
ValueStack策略允许通过一系列名称相同但类型不同的属性重用页面。
值栈技术非常著名。
不需要request、不需要session,直接从Action中取值。
7.类型转换:
Struts1ActionForm属性通常都是String类型。
Struts1使用Commons-Beanutils进行类型转换。
每个类一个转换器,对每一个实例来说是不可配置的。
Struts2使用OGNL进行类型转换。
提供基本和常用对象的转换器。
8.校验:
Struts1支持在ActionForm的validate方法中手动校验,或者通过CommonsValidator的扩展来校验。
同一个类可以有不同的校验内容,但不能校验子对象。
Struts2支持通过validate方法和Xwork校验框架来进行校验。
Xwork校验框架使用为属性类类型定义的校验和内容校验,来支持chain校验子属性。
9.Action执行的控制:
Struts1支持每一个模块有单独的RequestProcessors(生命周期),但是模块中的所有Action必须共享相同的生命周期。
(服务器重启时,Action生命周期结束,即生命周期无法控制)。
Struts2支持通过拦截器堆栈(InterceptorStacks)为每一个Action创建不同的生命周期。
堆栈能够根据需要和不同的Action一起使用。
(可以控制Action的生命周期)
简单的说:
struts1和struts2的核心原理不同:
struts1.X是基于servlet的
struts2是xwork的变体:
他的核心是filter
struts1是单力模式开发,
struts2是多力模式。
struts1的单力模式好处是节省内存,缺点是并发性查,非同步。
struts2好处是线程安全是同步的每次使用开辟新的内存空间,缺点是占用资源多。
Model1的原理:
Struts1的工作原理:
图2
它引入了"控制器"这个概念,控制器一般由servlet来担任,客户端的请求不再直接送给一个处理业务逻辑的JSP页面,而是送给这个控制器,再由控制器根据具体的请求调用不同的事务逻辑,并将处理结果返回到合适的页面。
因此,这个servlet控制器为应用程序提供了一个进行前-后端处理的中枢。
一方面为输入数据的验证、身份认证、日志及实现国际化编程提供了一个合适的切入点;另一方面也提供了将业务逻辑从JSP文件剥离的可能。
业务逻辑从JSP页面分离后,JSP文件蜕变成一个单纯完成显示任务的东西,这就是常说的View。
而独立出来的事务逻辑变成人们常说的Model,再加上控制器Control本身,就构成了MVC模式。
实践证明,MVC模式为大型程序的开发及维护提供了巨大的便利。
其实,MVC开始并不是为Web应用程序提出的模式,传统的MVC要求M将其状态变化通报给V,但由于Web浏览器工作在典型的拉模式而非推模式,很难做到这一点。
因此有些人又将用于Web应用的MVC称之为MVC2。
正如上面所提到的MVC是一种模式,当然可以有各种不同的具体实现,包括您自己就可以实现一个体现MVC思想的程序框架,Struts就是一种具体实现MVC2的程序框架。
它的大致结构如图三所示:
图三
图三基本勾勒出了一个基于Struts的应用程序的结构,从左到右,分别是其表示层(view)、控制层(controller)、和模型层(Model)。
其表示层使用Struts标签库构建。
来自客户的所有需要通过框架的请求统一由叫ActionServlet的servlet接收(ActionServletStruts已经为我们写好了,只要您应用没有什么特别的要求,它基本上都能满足您的要求),根据接收的请求参数和Struts配置(struts-config.xml)中ActionMapping,将请求送给合适的Action去处理,解决由谁做的问题,它们共同构成Struts的控制器。
Action则是Struts应用中真正干活的组件,开发人员一般都要在这里耗费大量的时间,它解决的是做什么的问题,它通过调用需要的业务组件(模型)来完成应用的业务,业务组件解决的是如何做的问题,并将执行的结果返回一个代表所需的描绘响应的JSP(或Action)的ActionForward对象给ActionServlet以将响应呈现给客户。
过程如图四所示:
图四
这里要特别说明一下的是:
就是Action这个类,上面已经说到了它是Struts中真正干活的地方,也是值得我们高度关注的地方。
可是,关于它到底是属于控制层还是属于模型层,存在两种不同的意见,一种认为它属于模型层,如:
《JSPWeb编程指南》;另一些则认为它属于控制层如:
《ProgrammingJakartaStruts》、《MasteringJakartaStruts》和《StrutsKickStart》等认为它是控制器的一部分,还有其他一些书如《StrutsinAction》也建议要避免将业务逻辑放在Action类中,也就是说,图3中Action后的括号中的内容应该从中移出,但实际中确有一些系统将比较简单的且不打算重用的业务逻辑放在Action中,所以在图中还是这样表示。
显然,将业务对象从Action分离出来后有利于它的重用,同时也增强了应用程序的健壮性和设计的灵活性。
因此,它实际上可以看作是Controller与Model的适配器,如果硬要把它归于那一部分,笔者更倾向于后一种看法,即它是Controller的一部分,换句话说,它不应该包含过多的业务逻辑,而应该只是简单地收集业务方法所需要的数据并传递给业务对象。
实际上,它的主要职责是:
校验前提条件或者声明
调用需要的业务逻辑方法
检测或处理其他错误
路由控制到相关视图
上面这样简单的描述,初学者可能会感到有些难以接受,下面举个比较具体的例子来进一步帮助我们理解。
如:
假设,我们做的是个电子商务程序,现在程序要完成的操作任务是提交定单并返回定单号给客户,这就是关于做什么的问题,应该由Action类完成,但具体怎么获得数据库连接,插入定单数据到数据库表中,又怎么从数据库表中取得这个定单号(一般是自增数据列的数据),这一系列复杂的问题,这都是解决怎么做的问题,则应该由一个(假设名为orderBo)业务对象即Model来完成。
orderBo可能用一个返回整型值的名为submitOrder的方法来做这件事,Action则是先校验定单数据是否正确,以免常说的垃圾进垃圾出;如果正确则简单地调用orderBo的submitOrder方法来得到定单号;它还要处理在调用过程中可能出现任何错误;最后根据不同的情况返回不同的结果给客户。
二、为什么要使用Struts框架
既然本文的开始就说了,自己可以建这种框架,为什么要使用Struts呢?
我想下面列举的这些理由是显而易见的:
首先,它是建立在MVC这种公认的好的模式上的,Struts在M、V和C上都有涉及,但它主要是提供一个好的控制器和一套定制的标签库上,也就是说它的着力点在C和V上,因此,它天生就有MVC所带来的一系列优点,如:
结构层次分明,高可重用性,增加了程序的健壮性和可伸缩性,便于开发与设计分工,提供集中统一的权限控制、校验、国际化、日志等等;其次,它是个开源项目得到了包括它的发明者CraigR.McClanahan在内的一些程序大师和高手持续而细心的呵护,并且经受了实战的检验,使其功能越来越强大,体系也日臻完善;最后,是它对其他技术和框架显示出很好的融合性。
如,现在,它已经与tiles融为一体,可以展望,它很快就会与JSF等融会在一起。
当然,和其他任何技术一样,它也不是十全十美的,如:
它对类和一些属性、参数的命名显得有些随意,给使用带来一些不便;还有如Action类execute方法的只能接收一个ActionForm参数等。
但瑕不掩瑜,这些没有影响它被广泛使用
为什么使用Struts2?
新版本的Struts2.0是struts的action架构和webwork的融合体.依照Struts2.0.1的发布公告,一些关键特性如下:
● 设计简单:
使用抽象类而不是接口是Struts1的一个设计上的问题,这已经在Struts2中得到了解决.在Struts2中绝大多数类都是基于接口的,并且它的绝大多数核心接口都是独立于HTTP的.Struts2的Action类是独立于框架的,可视为单纯的POJO.框架的组件都设法保持松耦合
● 单纯的Action:
Action都是单纯的POJO.任何含有execute()方法的java类都可以当作Action类来使用.甚至我们始终都不需要实现接口.反转控制会在开发Action类的时候得到介绍过,这能让Action中立于底层框架.
● 不再使用ActionForm:
ActionForm特性不再在Structs2中出现.简单的JavaBean即可对Action直接传递参数.不再需要全部使用String类型的参数.
● 简单的测试:
Struts2的Action是独立于HTTP并且中立于框架的.这使得Struts2的程序可以很容易的在没有模拟对象的情况下测试.
● 巧妙的默认值:
大多数配置元素都设有一个根据需要设定的默认值.甚至根据需要基于XML的默认配置文件都可以进行重写.
● 改良的结果集:
不像Struts1中的ActionForward,Struts2的结果集灵活的提供了多种类型的输出,事实上这促进了响应的准备工作.
● 更好的标签特性:
Struts2可以添加样式表驱动标记,这使我们创建相同的页面仅用更少的代码.Struts2的标签更有效而且是面向结果的.Struts2的标签标记可以通过修改基础样式表来修改.个别的标签标记可以通过编辑FreeMarker的模板来修改.JSP和FreeMarker都完全得到了支持.
● 引入注释:
在Struts2程序中,除了XML和Javaproperties配置文件外,Java5的注释也可以作为一种选择.注释使得XML的使用降至最低.
● 有状态的Checkbox:
Struts2中的checkbox不需要对false值进行特殊处理.
● 快速开始:
很多改变无需重启web容器即可实现.
● 自定义控制器:
Struts1可以自定义每一个模块的请求处理器,如果需要,Struts2可以自定义每一个Action的请求处理.
● 易与Spring整合:
Struts2的Action与Spring是友好的,只需添加Spring的bean
● 轻巧的插件:
Struts2可以通过添加一个Jar文件来进行扩展,不再需要手动配置!
● 支持AJAX:
AJAX主题对提升程序交互有着重要的意义.Struts2框架提供了一套标签来AJAX化你的程序甚至DOJO.AJAX特性包括:
1. AJAX客户端验证.
2. 支持远程表单提交.(同样适用于submit标签)
3. 先进的div模板提供动态重载部份HTML
4. 先进的模板提供远程加载和计算Javascript的能力.
5. AJAX-only选项卡面板的实现
6. 丰富的发布/订阅事件模型
7. 自动交互完善标签
深入全面阐释Struts2的方方面面
一、Struts概述
Struts是一个用来开发Model2应用程序的框架。
这个框架可以提高开发工作的速度,因为它提供的下面这些功能解决了Web应用程序开发过程中的一些常见问题:
∙对页面导航活动进行管理;
∙对来自用户的输入数据进行合法性验证;
∙统一的布局;
∙可扩展性;
∙国际化和本地化;
∙支持Ajax技术。
因为Struts是一个Model2框架,所以在使用Struts时还应该遵守以下几条不成文的规定。
∙不要在JSP页面里嵌入Java代码,应该把所有的业务逻辑包含在一些被称为“动作类”(actionclass)的Java类里。
∙在JSP页面里使用ExpressionLanguage(OGNL)去访问有关的模型对象。
∙尽量避免编写自定义标签(因为自定义标签的代码比较难以编写)。
二、升级到Struts2
你也许用过Struts1编程,这里提供了一个关于Struts2新功能的简要介绍。
∙在Struts1里需要使用一个像ActionServlet类这样的东西作为servlet控制器;Struct2使用了一个过滤器来完成同样的任务。
∙在Struts2里没有任何动作表单。
在Struts1里,每个HTML表单都对应着一个ActionForm实例,你可以从动作类访问这个动作表单,并用它来填充数据传输对象。
在Struts2里,HTML表单将被直接映射为一个POJO,而不再需要你创建一个数据传输对象,因为没有动作表单,维护工作变得简单容易了,你不再需要与那么多的类打交道。
∙问题来了:
没有了动作表单,怎样才能在Struts2里通过编程对用户输入进行合法性验证呢?
答案是把验证逻辑编写在动作类里。
∙Struts1通过几个标签库提供了一批定制标签供程序员在JSP页面里使用,其中最重要的是HTML标签库、Bean标签库和Logic标签库。
Servlet2.4里的JSTL和EL(ExpressionLanguage,表达式语言)经常被用来代替Bean和Logic标签库。
Struts2为程序员准备了一个应有尽有的标签库,你不再需要JSTL,但在某些场合你可能仍需要EL。
∙在Struts1里,你还需要用到一些Struts配置文件,其中最主要的是存放在各Web应用程序里的WEB-INF子目录里的struts-config.xml(默认文件名)。
在Struts2里,你仍需要用到多个配置文件,但必须把它们存放在WEB-INF/classes子目录或它的某个下级子目录里。
∙要想使用Struts2,你的系统里必须有Java5和Servlet2.4(或更高版本)。
之所以需要有Java5,是因为Java5里新增加的注解在Struts2里扮演着重要角色。
我们撰写本书时,Java6已经发布,Java7也指日可待,你很可能已经在使用Java5或Java6了。
∙在Struts1里,动作类必须扩展自org.apache.struts.action.Action类。
在Struts2里,任何一个POJO都可以是一个动作类。
不过,我们将在本书第3章说明,在Struts2里最好对ActionSupport类进行扩展。
在此基础上,可用一个动作类来完成相关的动作。
∙Struts2在JSP页面里使用OGNL来显示各种对象模型,而不再是JSPEL和JSTL。
原本是Struts1组件之一的Tiles现在已经发展为一个独立的Apache
HTTP没有“类型”的概念,在HTTP请求里发送的值都是字符串。
在把表单字段映射到非String类型的动作属性时,Struts会自动对这些值进行必要的转换。
这一章将解释Struts如何完成这类转换,你还将学到如何为更加复杂的情
spring工作机制及为什么要用?
1.springmvc请所有的请求都提交给DispatcherServlet,它会委托应用系统的其他模块负责负责对请求进行真正的处理工作。
2.DispatcherServlet查询一个或多个HandlerMapping,找到处理请求的Controller.
3.DispatcherServlet请请求提交到目标Controller
4.Controller进行业务逻辑处理后,会返回一个ModelAndView
5.Dispathcher查询一个或多个ViewResolver视图解析器,找到ModelAndView对象指定的视图对象
6.视图对象负责渲染返回给客户端。
为什么用:
AOP让开发人员可以创建非行为性的关注点,称为横切关注点,并将它们插入到应用程序代码中。
使用AOP后,公共服务(比如日志、持久性、事务等)就可以分解成方面并应用到域对象上,同时不会增加域对象的对象模型的复杂性。
IOC允许创建一个可以构造对象的应用环境,然后向这些对象传递它们的协作对象。
正如单词倒置所表明的,IOC就像反过来的JNDI。
没有使用一堆抽象工厂、服务定位器、单元素(singleton)和直接构造(straightconstruction),每一个对象都是用其协作对象构造的。
因此是由容器管理协作对象(collaborator)。
Spring即使一个AOP框架,也是一IOC容器。
Spring最好的地方是它有助于您替换对象。
有了Spring,只要用JavaBean属性和配置文件加入依赖性(协作对象)。
然后可以很容易地在需要时替换
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Java strutsspringhibernate 精通 SSH 框架 底层 机制 原理