目录
1. 框架简介 (2)
2. 框架结构 (3)
2.1控制层 (3)
2.2 业务逻辑层 (3)
2.3 持久层 (4)
2.4 小结 (4)
3. 框架的配置过程 (4)
3.1添加jar包 (4)
3.2添加配置文件 (4)
3.2.1 web.xml加载过程 (5)
3.2.2 SSI整合时的一些配置文件 (7)
3.2.3 如何启动Spring容器 (8)
3.2.4 整合Struts2 (8)
3.2.5 Spring整合ibatis配置文件 (9)
3.2.6、Struts.xml (9)
1.框架简介
MVC对于我们来说，已经不陌生了，它起源于20世纪80年代针对smalltalk 语言的一种软件设计模式，现在已被广泛应用。近年来，随着java的盛行，MVC 的低耦合性、高重用性、可维护性、软件工程的可管理性等诸多优点使其在java 平台中很受欢迎，其间，也诞生了许多优秀的MVC框架，如专注于控制层的Struts、WebWork, Struts2, JSF等框架，专注于业务逻辑方面的Spring框架、专注于持久层的Hibernate、iBatis、Castor、JORM等框架。由于最近用了一次SSI 框架，因此本文主要是对Strtus2、Spring、iBatis三个开源的MVC框架进行一个小结。
Struts2主要来源于webwork框架，与Struts1相比，在数据传递方面，Struts2提供了更加强大OGNL标签功能，使其能够通过在action中定义变量来直接与jsp页面中的数据进行相互传值，省去了Struts1中的formbean；而在跳转控制方面，Struts2简化了配置文件的信息量，使页面和action之间的交换更加的简洁和直观，便于开发人员的管理。
Spring功能非常的强大，比如它的控制反转/依赖注入机制，省去了我们自己书写工厂模式的工作，实现类对我们将要用到控制类、业务逻辑类、数据访问类、以及JNDI或者JDBC数据源的托管；Spring对AOP支持使我们在用户chmod.html' target='_blank'>权限控制、事务处理方面节省了很多工作量；
iBatis则是一种轻量级的OR Mapping框架，与Hibernate相比，iBatis 提供了半自动化对象关系映射的实现，开发人员需要编写具体的sql语句，为系统设计提供了更大的自由空间，为sql语句优化提供了便利。
2. 框架结构
下面这张图就是我们所用到的这三种框架的结合体，下面对其作以简单介绍。
2.1控制层
在控制层，利用Strtus2标签功能，在Action中直接与jsp页面上的数据进行交互。在调用业务逻辑层应用时，Struts2提供了对Sping的支持。开发人员需要完成对struts.xml的配置工作和对各个Action类的编写。
2.2 业务逻辑层
在业务逻辑层，利用Spring框架的依赖注入实现对业务逻辑类和DAO类的
实例托管；在事务处理方面，利用Spring提供的面向切面的事务处理功能，使对数据的事务控制脱离于数据访问接口实现；在对象关系映射方面，利用Spring 对数据库连接池的托管和对iBatis框架的支持。开发人员需要完成对数据源的配置、对不同模块所对应的application*.xml文件的配置，以及对业务逻辑接口的定义和业务逻辑实现的编写。
2.3 持久层
在持久层，利用iBatis提供的半自动化对象关系映射的实现，开发人员需要编写具体的sql语句，为系统设计提供了更大的自由空间。另外，开发人员需要完成对SqlMapConfig.xml和*SqlMap.xml的配置，以及对DAO接口的定义和DAO接口的实现。
2.4 小结
在各层之间进行交换的过程中，利用数据传输类进行数据的传递和交互。其中，数据传输类与数据库表一一对应。
SSI框架能够降低我们代码的耦合度，增强了代码的健壮性和可重用性，加快了开发速度，但是也有一些不足之处，比如由于三种框架的配置文件较多，也给我们带来了一些不便，特别是对于较小的应用来说更是如此
3. 框架的配置过程
3.1添加jar包
首先引入struts2 spring ibatis 各自的jar包在此就不一一罗列了。
3.2添加配置文件
我们首先从web.xml文件说起
3.2.1 web.xml加载过程
1 启动WEB项目的时候，容器(如:Tomcat)会读他的配置文件web.xml读两个节点
2 紧接着，容器创建一个ServletContext(上下文) 这个WEB项目所有部分都将共享这个上下文
3 容器将
4 容器创建
5 在监听中会有contextInitialized(ServletContextEvent args)初始化方法，在这个方法中获得：
ServletContext = ServletContextEvent.getServletContext();
context-param的值= ServletContext.getInitParameter("context-param的键");
web.xml节点加载顺序
节点的加载顺序与它们在web.xml文件中的先后顺序无关。即不会因为filter写在listener的前面而会先加载filter最终得出的结论是:listener->filter->servlet
同时还存在着这样一种配置节点：context-param，它用于向ServletContext 提供键值对，即应用程序上下文信息。我们的 listener, filter 等在初始化时会用到这些上下文的信息，那么context-param 配置节是不是应该写在 listener 配置节前呢？实际上 context-param 配置节可写在任意位置，因此真正的加载顺序为：
context-param -> listener -> filter -> servlet
加载spring
org.springframework.web.context.ContextLoaderListener
最终结论：
web.xml 的加载顺序是：[context-param -> listener -> filter -> servlet -> spring] ，而同类型节点之间的实际程序调用的时候的顺序是根据
对应的 mapping 的顺序进行调用的。
打开web.xml文件，根据实际需要添加如下内容
org.springframework.web.util.Log4jConfigListener
org.springframework.web.context.ContextLoaderListener
3.2.2 SSI整合时的一些配置文件
1,contextConfigLocation:Spring容器启动时需要加载Spring的配置文件。默认是/WEB-INF目录下的applicationContext.xml文件
当然也可以放在classpath下，可以包括多个spring配置文件，这就得依靠contextConfigLocation
如果web.xml中没有配置context-param，spring的配置就像如上这段代码示例一下，自动去WEB-INF目录下寻找applicationContext.xml。此时，如果你修改applicationContext.xml的名称，或者移除它，再启动服务器，你会得到如下异常信息：
1.nested exception is java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/applicationContext.xml] 这证实了其默认配置。默认配置情况下spring只会去WEB-INF目录下寻找配置文件，而不会去classpath下寻找。
如果我们不想将配置文件放在WEB-INF目录下呢？开发中经常在src下面创建一个config目录，用于存放配置文件。此时，对应的param-value改为：classpath:config/applicationContext.xml。
一定要加上classpath，这告诉spring去classes目录下的config目录下面寻找配置文件。
3.2.3 如何启动Spring容器
两种方法，一种以listener启动一种以load-on-startup Servlet。
org.springframework.web.context.ContextLoaderListener
第二种
org.springframework.web.context.ContextLoaderServlet
3.2.4 整合Struts2
org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecut
eFilter
3.2.5 Spring整合ibatis配置文件
3.2.6、Struts.xml
constant配置struts的常量(也可在struts.properties)文件中配置，将struts的对象工厂托由spring管理。