java培训资料

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

SSH篇(后台)

一、SSH概述

1.1 SSH的含义

当前J2EE企业级应用分为三层:表现层-业务层-数据源层,而SSH代表了每一层的具体实现,它是三种流行的开源框架的缩写,S-Struts,S-Spring,H-Hibernate。这三者的组合是当前J2EE开发的标准模式,也代表了J2EE正在朝着简化复杂性,轻量化方向发展,最新J2EE 6已证明了这种趋势。

1.2 J2EE开发模式的演变

J2EE应用一直采用三层加构,即表现层-业务层-数据源层。

旧石器时代:J2EE应用采用表现层-远程EJB-实体EJB(或JDBC),这是最为正宗也是最复杂的J2EE开发,适用于银行等小部分项目;随后由于微软.NET的兴起以及其对J2EE的挑战,正宗的J2EE出现了一个变种:表现层-本地EJB-Ibatis,在这种模型中业务层选择了本地EJB,同时数据源层也改为Ibatis,这种模式极大的提高性能,华为大部分项目采用这种构架。在这两种架构中,由于采用了EJB组件模型,从而依赖于EJB容器,而EJB容器以一种全无或全有的方式提供服务,同时业务实现也受制于容器。这种开发模式导致了以下复杂性:依赖于应用服务器,不可移植,开发困难,无法在容器外测试,部署复杂,效率低下。

新石器时代:在新石器时代依然采用了三层加构,只是抛弃了EJB,而采用了Spring等轻量级容器,同时持久化由全自动的Hibernate承担。在这种架构中,由于放弃了EJB,放弃了全功能的应用服务器,在节省了软件许可费用的同时也大大提高了软件开发效率。由于web服务器的可移植也好于应用服务器,从而使得J2EE应用可顺利移植。

1.3 SSH与传统开发的比较

从上面所述可以看出传统J2EE开发和SSH开发的不同。简言之,传统J2EE开发采用EJB组件在限制了业务实现的同时也极其复杂,只适用银行等一部分应用;SSH不强制采用应用服务器,不限制业务实现,透明的持久化从而减化了开发的复杂度,提高了开发效率。

二、Struts-WEB层开发的标准

2.1 Struts简介

Struts是Apache软件基金会的一个开源项目。采用Servlet/JSP技术,实现了基于J2EE Web应用的MVC设计模式的应用框架,是MVC经典设计模式中的一个经典产品。使用标准的JSP以外,还提供了大量的标签库使用,同时也可以与其他表现层组件技术(产品)进行整合。Struts出现之前J2EE Web层没有统一标准,各个公司都是自有框架,给从业者,企业带来了诸多不便。Struts采用了经典MVC设计,从而事实上成为WEB层开发的标准

2.2 Struts的原理

在谈到Struts前,简单讲下MVC设计模式。MVC即Model-View-Controller的缩写,MVC减弱了业务逻辑接口和数据接口之间的耦合,同时让视图层更富于变化。

MVC的工作原理,如下图1所示:

控制器(Controller)-负责转发请求,对请求进行处理。

视图(View)- 界面设计人员进行图形界面设计。

模型(Model)- 程序员编写程序应有的功能(实现算法等等)、数据库专家进行数据管理

和数据库设计(可以实现具体的功能)。

Struts 是MVC的一种实现,它将Servlet和JSP 标记用作实现的一部分。Struts继承了MVC 的各项特性,并根据J2EE的特点,做了相应的变化与扩展。Struts的体系结构与工作原理如下图2所示:

从图2中我们可以知道,Struts的体系结构包括模型(Model),视图(View)和控制器(Controller)三部分。

下面让我们从用户发出请示角度来看看struts的体系结构(Model 2)与工作原理:

(1)首先,用户(通常通过浏览器,如IE)发出请求,Struts的控制器(Controller Servlet)得到请求。

(2)Struts控制器通过配置文件得到业务逻辑处理Action,并调用Action的处理用户请求。(3)Action处理业务业务逻辑(可能查找数据库或调用别的系统),处理完成后,填充相关的Model对象,并把控制权返回控制器。

(4)控制器选择相应的视图(视图从模型里取出数据),并返回给用户。

2.3 Struts2简介

Struts2提供了对MVC的一个清晰的实现,这一实现包含了很多参与对所以请求进行处理的关键组件,如:拦截器、OGNL表达式语言、堆栈。下图是Struts2的处理流程。

一个请求在Struts2框架中的处理大概分为以下几个步骤

1 客户端初始化一个指向Servlet容器(例如Tomcat)的请求

2 这个请求经过一系列的过滤器(Filter)(这些过滤器中有一个叫做ActionContextCleanUp 的可选过滤器,这个过滤器对于Struts2和其他框架的集成很有帮助,例如:SiteMesh Plugin)

3 接着FilterDispatcher被调用,FilterDispatcher询问ActionMapper来决定这个请是否需要调用某个Action

4 如果ActionMapper决定需要调用某个Action,FilterDispatcher把请求的处理交给ActionProxy

5 ActionProxy通过Configuration Manager询问框架的配置文件,找到需要调用的Action类

6 ActionProxy创建一个ActionInvocation的实例。

7 ActionInvocation实例使用命名模式来调用,在调用Action的过程前后,涉及到相关拦截器(Intercepter)的调用。

8 一旦Action执行完毕,ActionInvocation负责根据struts.xml中的配置找到对应的返回结果。返回结果通常是(但不总是,也可能是另外的一个Action链)一个需要被表示的JSP或者FreeMarker的模版。在表示的过程中可以使用Struts2 框架中继承的标签。在这个过程中需要涉及到ActionMapper

2.4 Struts,Struts2的比较

在Action 实现类方面的对比:Struts 1 要求Action 类继承一个抽象基类;Struts 1 的一个具体问题是使用抽象类编程而不是接口。Struts 2 Action 类可以实现一个Action接口,也可以实现其他接口,使可选和定制的服务成为可能。Struts2 提供一ActionSupport 基类去实现常用的接口。即使Action 接口不是必须实现的,只有一个包含execute 方法的POJO 类都可以用作Struts 2 的Action 。

线程模式方面的对比:Struts 1 Action 是单例模式并且必须是线程安全的,因为仅有Action 的一个实例来处理所有的请求。单例策略限制了Struts 1 Action 能做的事,并且要在开发时特别小心。Action 资源必须是线程安全的或同步的;Struts 2 Action对象为每一个请求产生一个实例,因此没有线程安全问题。

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

可测性方面的对比:测试Struts 1 Action 的一个主要问题是execute 方法依赖于Servlet API,

相关文档
最新文档