Struts+Spring+Hibernate的Web应用执行过程

struts1和spring有两种整合的方法  一种是action和spring bean映射；一种是将action交给spring初始化

第一种方式：访问.do的URL->tomcat接收到request-〉到Struts配置文件里找对应的action-〉找到对应的action组件（Action那个类）-〉这个类对request进行一系列处理-〉调用spring提供的某个service的注入实例的方法->由这个方法返回值-〉响应输出

第二种方式：访问.do的URL->tomcat接收到request-〉到Struts配置文件里找对应的action-〉找不到对应的action组件（Action那个类）-〉去spring配置文件里找这个Action的映射，找到类-〉这个类对request进行一系列处理-〉调用spring提供的某个service的注入实例的方法->由这个方法返回值-〉响应输出

（Struts1很久不用了，也许有差漏）

hibernate和spring的整合比较复杂，建议找人当面讲

粗谈Struts——从执行顺序来看Struts

1.在web.xml中的配置
     
Struts在web.xml中的配置通常是自动生成的，这里不用赘述。只有一点应该说一下，那就是为ActionServlet这个servlet配置<load-on-startup>，而且应该让它的数值小一些，这样能让这个ActionServlet这个系统核心控制器早一点启动。

2.用户的请求

用户提交表单时，表单的action属性通常应以.do结束。当然，如果不写的话，系统也会默认（添加）以.do结束。以.do结束的原因是因为，在web.xml中我们通常都是配置拦截以.do结束的请求。
   3.定位Action
     
ActionServlet拦截到用户的请求后，并不自己处理，它委托给RequestProcessor进行处理。RequestProcessor使用请求URI与struts-config.xml文件中的Action的path属性进行对比，从而确定由哪个Action来处理这个请求。
   4.填充ActionForm

确定下来由哪个Action来处理请求后，系统会去检查Action的name属性。然后，根据name属性的值再在这个文件中去找对应的ActionForm来接受有户提交的表单的内容。在ActionForm中通常有一个方法ActionErrors validate(ActionMapping
mapping,HttpServletRequest request)需要重写，该方法是用来检验用户的输入是否合法的。不过，现在Struts已经不在提倡这种验证方法了。
   5.对表单的验证

借助于jakarta-oro.jar和commons-validator.jar的支持，Struts的校验功能非常的强大。此种的验证牵涉的内容很多，在此不做细说。如果，校验出错误，则将错误送到Action的input属性指定的页面去处理。
   6.Action处理

若校验通过，则Action做一些业务逻辑上的处理，其实Action就是业务逻辑处理器。处理之后，把处理的结果放到request（或Session等）里，然后转发到全局转发所指定的jsp页面或在Action的配置时配置的局部转发所指定的jsp页面里。
   7.结果的显示

在jsp页面中对Action处理的结果进行输出显示。

粗谈Spring——从执行顺序来看说Spring

1.Spring的加载（实例化）

如果不与Struts整合的话，Spring的加载是在Web程序的web.xml中配置的，在web.xml
中有两种选择，一种是ContextLoaderListener，另一种是ContextLoaderServlet。

如果与Struts进行整合，则Spring的加载是在struts-config.xml中配置的。
   2.容器后处理器
      在容器实例化之后可以对Spring容器进行一些操作，这个通过实现接口BeanFactoryPostProcessor接口来实现，该接口有一个方法void
postProcessorBeanFactory(ConfigurableListableBeanFactory
beanFactory)。这个接口有两个很有用的实现类，是Spring已经实现好的，它们是PropertyPlaceholderConfigurer(属性占位符配置器)和PropertyOverrideConfigurer(另一种属性占位符配置器)。
   3.与Spring容器的交互

对容器的处理操作结束以后，我们就能和Spring容器进行交互了，我们可以实现FactoryBean，FactoryBeanAware接口等方法获取BeanFactory实例，然后用之。
   4.配置bean和依赖关系

这包括配置依赖，注入属性值，注入field值，注入方法返回值，bean的继承。这些配置的过程中还包括配置强制初始化bean（depends-on），自动装配(autowire)，依赖检查(dependency-check)，这三项都是bean的属性（不是子元素）。
   5.对容器中的bean实例化的管理——bean后处理器
     
bean后处理器必须实现BeanPostProcessor接口，该接口中有两个方法，一个是Object postProcessBeforeInitialization(Object
bean,String name) throws BeansException
和 Object postProcessAfterInitialization(Object
bean,String name) throws BeansException，前一个方法是在实例化之前对该bean进行处理，后一个方法是在实例化之后对该bean进行处理。
   6.对bean生命周期的管理

对bean生命周期的管理有两个时机：一，在注入依赖关系之后；二，在即将销毁bean之前。

在注入依赖关系之后管理有两种方式：一，使用init-method属性；二，InitialingBean接口，它只有一个void afterPropertiesSet() throws
Exception方法。
      在bean销毁之前管理时也有两种方式：一，使用destroy-method属性；二，DisposableBean接口，它只有一个void destroy() throws Exception方法。
　　　这里要说明的是，如果同时配了属性，也实现了方法。则先执行接口的方法，再执行配置的属性指定的方法。
　　　如果既用了bean后处理器，有对bean的生命周期进行管理，则执行的顺序是：Object postProcessBeforeInitialization(Object
bean,String name) throws BeansException，void afterPropertiesSet() throws
Exception，init-method，Object postProcessAfterInitialization(Object
bean,String name) throws BeansException。
   7.创建bean实例

创建bean实例有三种方法：
　　　   1.调用构造器创建一个bean实例。
　　　　
2.BeanFactory调用某个类的静态工厂方法创建bean。
　　　　
3.BeanFactory调用实例工厂方法创建bean。
   8.依赖注入

注入的顺序是先实例化本bean（它需要容器向它注入其它的bean）,在实例化用来向本bean注入的bean，然后执行注入。当然，这种顺序是可以改变的，可以用强制实例化bean来改变这种顺序。强制实例化bean在前面已经说过。

注入的方式有两种，一种是设值注入，另一种是构造注入。

粗谈Hibernate——从执行顺序来看Hibernate

1.实例化Configuration对象

Hibernate在WEB-INF下查找hibernate.cfg.xml配置文件,根据hibernate.cfg.xml配置文件中配置的信息实例化Configuration对象

。如果使用了事件系统的话，在实例化Configuration对象后还应对事件监听器进行注册。这里值得一提的是配置的问题。一般为每个持久化类配置一个映射文件，其中包括基本映射和关系映射。在hibernate.cfg.xml中，使用<session-factory
/>元素下的<mapping resource="Xxxx.hbm.xml"
/>子元素来罗列所有的持久化类的映射文件，使Configuration在实例化时加载这些持久化类的配置信息。

2.实例化SessionFactory对象

通常Configuration的对象先调用configure()方法，以次来或得一个返回值，该返回值调用buildSessionFactory()方法来实例化SessionFactory对象。

3.实例化Session对象

有了SessionFactory对象后，它可以调用方法openSession()或openSession(Interceptor it)来实例化一个Session对象。如果没有使用拦截器就使用openSession()方法，使用了拦截器的话则使用openSession(Interceptor it)。这里的拦截器是一种事件框架，它实现了Interceptor接口的类，通过Interceptor接口，可以在数据进入数据库之前，对数据进行最后的检查，如果数据不符合要求，则可以修改数据，从而避免非法数据进入数据库。其实，通过Configuration还可以启用全局拦截器。1中所说的事件系统是功能更强大的事件框架，该事件系统可以替代拦截器，也可以作为拦截器的补充来用，详细内容请参看“[读书总结]Hibernate的事件框架
”那篇文章。

4.开始事务

在对数据库访问之前应该设置事务的开始点，告诉系统从哪儿开始对数据库进行操作，以便于让系统成功提交事务时的作用范围。

5.访问数据库

对数据库的操作无外乎对数据库中的数据进行增，删，改，查等操作。Hibernate的查询体系是非常强大的，它包括HQL查询，条件查询以及SQL查询等。

这里对Hibernate的查询不作细说，仅谈谈Hibernate的数据过滤。数据过滤不是一种常规的数据查询方法，而是一种整体的筛选方法。通过过滤数据也可以对数据进行筛选。过滤器与定义在类和集合上映射文件中的“where”约束子句非常相似，区别是过滤器可以带参数，应用程序可以在运行时决定是否启用给定的过滤器，以及使用什么样的参数值。而映射文件的“where”属性将一直生效，且无法动态传入参数。过滤器的用法与视图很相似，区别是试图在数据库中已经完成定义，而过滤器则还需要在应用程序中确定参数值。Hibernate过滤器起作用的时机要比一般的查询语句早。也就是说，在使用过滤器的情况下，进行数据查询时，过滤器先起作用，过滤下一些数据后再让查询语句去查。

6.提交事务

提交事务时可能成功，也可能失败。若提交失败则进行回滚，回滚时取消在事务开始以来的所有操作，这就体现了事务的原子性。

7.关闭Session

最后，关闭刚才实例化的Session对象。