华为外包java面试题

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，