Springmvc整合Spring时，Spring配置文件扫描包与springmvc配置文件扫描包的不同（Spring父子容器）

        前面的几篇博客中，讲解到在ssm框架的集成过程中，我们发现sping的配置文件--applicationContext.xml文件负责扫描service层和dao层的注解，而spingmvc的配置文件---sping-mvc.xml文件负责扫描controller文件。

       为什么会这样处理呢？本篇文章就此进行深入研究（本文用到的图都是基于网上其他博主的博客），进入主题：

目录

抛出一个问题：我们在搭建ssm框架时，声明式事务失效的原因？

（1）Spring作为父容器，SpringMVC作为子容器

（2 ）现在放在具体的项目的配置文件进行研究以下几种配置情况

1、只在applicationContext.xml中配置如下

2、只在springmvc.xml中配置

3、不正常情况下，Spring的配置文件扫描service层和dao层以及controller层，springmvc也扫描controller

4、正常情况下，Spring的配置文件扫描service层和dao层，springmvc扫描controller

（3）关于sping与springmvc的一些疑问

1. 为什么使用Spring ?

2、如果不用Spring容器，直接把所有层放入SpringMVC容器中可不可以？

3、那么为什么我们在项目中还要联合用到Spring容器和SpringMVC容器？ 

4、事务为什么加在service层而不加在dao层

      首先理解 什么是事务？

5、以上是传统型SSM（spring+springmvc+mybatis）配置时，父类容器负责扫描装配service层和dao层，子类容器负责扫描装配controller层，但是在轻量化的javaEE开发中，我们可以不用spring框架，只是利用spinrgmvc+mybatis即可

---

抛出一个问题：我们在搭建ssm框架时，声明式事务失效的原因？

      根本原因：由子容器扫描装配了@Service 注解的实例。

      spring的context是父子容器，由ServletContextListener 加载spring配置文件产生的是父容器，springMVC加载配置文件产生的是子容器，子容器对Controller进行扫描装配时装配了@Service注解的实例 (@Controller 实例依赖@Service实例)，而该实例理应由父容器进行初始化以保证事务的增强处理，所以此时得到的将是原样的Service没有经过事务加强处理，故而没有事务处理能力。

（1）Spring作为父容器，SpringMVC作为子容器

     启动一个web.xml文件时，首先配置的是Spring容器的初始化加载的application文件，然后是SpringMVC的前端控制器（DispatchServlet），当配置完DispatchServlet后会在Spring容器中创建一个新的容器。其实这是两个容器，Spring作为父容器，SpringMVC作为子容器。

用一张图加以理解：

 

         平时我们在项目中注入关系是这样的顺序（结合图来说）：在Service中注入Dao（初始化自动注入，利用@Autowired），接着在Controller里注入Service（初始化自动注入，利用@Autowired），看图，这就意味这作为SpringMVC的子容器是可以访问父容器Spring对象的。

        那么问大家一个问题。要是反过来呢，你把Controller注入到Service中能行么？ 
                 肯定是不行的啊！(如图，这也说明了父容器是不能调用子容器对象的) 

       如果Dao,Serive,Controller要是都在Spring容器中，无疑上边的问题是肯定的，因为都是在一个bean里，一个容器中。

 

（2 ）现在放在具体的项目的配置文件进行研究以下几种配置情况

1、只在applicationContext.xml中配置如下

    <context:component-scan base-package="com" />

      启动正常，但是任何请求都不会被拦截，简而言之就是@Controller失效，出现404错误。

分析：

           此时的Spring容器中就会扫描到@Controller,@Service,@Rep