近期学习的知识梳理

1.Spring框架的工作流程：（注意与SPring MVC是有区别的）

1.浏览器点击查看所有用户信息
2.到达Spring框架
3.Spring框架进入到控制层，控制层的作用是接收前端请求，并获取到业务数据，返回给前端
4.控制层进入到业务层，业务层的作用是将从数据库拿到的数据组装成业务需要的数据
5.业务层进入到数据持久层，数据持久层的作用是操作数据库，获取到表中数据。
6.数据持久层再到数据库中
7.数据库返回到数据持久层
8.数据持久层返回到业务层
9.业务层返回到控制层
10.控制层回到Spring
11.Spring返回到浏览器，经过渲染最后显示出来。

Spring MVC调用流程：
1.客户端通过url发送请求
2-3.核心控制器Dispatcher Servlet接收到请求，通过系统或自定义的映射器配置找到对应的handler，并将url映射的控制器controller返回给核心控制器。
4.通过核心控制器找到系统或默认的适配器
5-7.由找到的适配器，调用实现对应接口的处理器，并将结果返回给适配器，结果中包含数据模型和视图对象，再由适配器返回给核心控制器
8-9.核心控制器将获取的数据和视图结合的对象传递给视图解析器，获取解析得到的结果，并由视图解析器响应给核心控制器
10.核心控制器将结果返回给客户端

这两者之间还是有一些区别的

2.RequestMapping的含义及用法

@RequestMapping这个注解会将 HTTP 请求映射到 MVC 和 REST 控制器的处理方法上。
@RequestMapping 注解可以在控制器类的级别和/或其中的方法的级别上使用。
在类的级别上的注解会将一个特定请求或者请求模式映射到一个控制器之上。之后还可以另外 添加方法级别的注解来进一步指定到处理方法的映射关系。
下面是一个同时在类和方法上应用了 @RequestMapping 注解的示例：

@RestController  
@RequestMapping("/login")  
public class IndexController {  
    @RequestMapping("/")  
    String get() {  
        //mapped to hostname:port/login/  
        return "Hello from login";  
    }  
    @RequestMapping("/admin")  
    String index() {  
        //mapped to hostname:port/login/admin/  
        return "Hello as admin";  
    }  
}  

如上述代码所示，到 /home 的请求会由 get() 方法来处理，而到 /home/index 的请求会由 index() 来处理。

**@RequestMapping 来处理多个 URI **

当然也可以将多个请求映射到一个方法上去，只需要添加一个带有请求路径值列表的 @RequestMapping 注解就行了。

@RestController  
@RequestMapping("/home")  
public class IndexController {  
  
    @RequestMapping(value = {  
        "",  
        "/page",  
        "page*",  
        "view/*,**/msg"  
    })  
    String indexMultipleMapping() {  
        return "Hello from index multiple mapping.";  
    }  
}  

在这段代码中所示，@RequestMapping 支持统配符以及ANT风格的路径。前面这段代码中，如下的这些 URL 都会由 indexMultipleMapping() 来处理：

• localhost:8080/home
• localhost:8080/home/
• localhost:8080/home/page
• localhost:8080/home/pageabc
• localhost:8080/home/view/
• localhost:8080/home/view/view

3.service,controller的含义及

从MVC的三层模型开始，三层模型的设计之初，就是为了将业务层（controller）、视图层（view）以及模型层（modal）区分开来。需要注意的是，这里没有数据库这个概念，所以模型层会有一些冗杂，两个表的联合查询出来的数据，会被封装成一个模型交给控制层；同样的，控制层因为没有服务的概念，如果项目比较大，也会变的有些冗余。

基于controller和modal层并没有很好的实现模块化，因此，我们将modal层去掉，改为更加原子化的dao层；同时，将controller层的业务逻辑，划分成多个服务。每个服务可以组合使用dao层数据，组装成一个服务，比如用户的注册服务；而controller层，调用多个service服务完成url请求。

简单来说，就是增加service层，替换modal层，第一是细化了数据模型，使得我们在改动某张表时，只需要改动dao层实现即可，最大化的减少了代码的改动成本；当然，更多的情况是service服务和controller可能都需要更改； service层将controller的逻辑分类，保证了controller的逻辑更加清晰。

举个生活中的例子，用户预约某个酒店的客房，这是酒店首先会调用验证服务对用户提供的信息进行验证，之后调用预约服务进行预约，如果预约失败，酒店可能会把客户的预约信息提交给另外一家酒店请求它们的预约服务，然后将结果返回给客户；

对于服务层来说，需要判断酒店是否有空余客房，之后修改客房信息，同时将客房和用户信息存入临时表。这里至少需要两种不同的dao层服务实现service。

所以整体上来看，controllrt->service->dao至少是一对一，更多的情况下是一对多。这也就是service层存在的意义了。

总结：
controller层，从字面上理解是控制器，所以它是负责业务调度的，所以在这一层应写一些业务的调度代码；具体的业务处理应放在service层中去写，而且service层不单纯是对于dao层的增删改查的调用，service是业务层，所以应该更切近于具体业务功能要求，所以在这一层，一个方法所体现的是一个可以对外提供的功能，比如购物商城中的生成订单方法，这里面就不简单是增加个订单记录那么简单，我们需要查询库存，核对商品等一系列实际业务逻辑的处理；

4.依赖注入的含义

Spring框架的核心功能之一就是通过依赖注入的方式来管理Bean之间的依赖关系。

了解过设计模式的朋友肯定知道工厂模式吧，即所有的对象的创建都交给工厂来完成，是一个典型的面向接口编程。这比直接用new直接创建对象更合理，因为直接用new创建对象，会导致调用者与被调用者的硬编码耦合；而工厂模式，则把责任转向了工厂，形成调用者与被调用者的接口的耦合，这样就避免了类层次的硬编码耦合。这样的工厂模式确实比传统创建对象好很多。但是，正如之前所说的，工厂模式只是把责任推给了工厂，造成了调用者与被调用者工厂的耦合。

Spring框架则避免了调用者与工厂之间的耦合，通过spring容器“宏观调控”，调用者只要被动接受spring容器为调用者的成员变量赋值即可，而不需要主动获取被依赖对象。这种被动获取的方式就叫做依赖注入，又叫控制反转。依赖注入又分为设值注入和构造注入。而spring框架则负责通过配置xml文件来实现依赖注入。而设值注入和构造注入则通过配置上的差异来区分。

5.context-param中读取的配置文件、DispatcherServlet中读取的配置文件的差别

web工程大多都需要配置web.xml文件，web.xml文件主要用来配置Listener、Filter、Servlet等。web.xml文件包括xml文件头，DOCTYPE声明，web-app元素。

web.xml的加载过程
在web-app元素内，元素的配置顺序与工程的加载顺序无关，web.xml的加载过程为：

1. 启动一个web项目，web容器（如tomcat）读取web.xml文件，读取其中的配置信息
2. 容器创建一个servlet上下文（servletContext），这个web项目所有部分共享这个上下文
3. 容器将< context-param > 转换为键值对，交给servletContext
4. 容器创建< listener >中的监听器实例
5. 触发contextInitialized方法，listener被调用（当Servlet 容器启动或终止Web 应用时，会触发ServletContextEvent 事件，该事件由ServletContextListener 来处理。在 ServletContextListener 接口中定义了处理ServletContextEvent 事件的两个方法contextInitialized；contextDestroyed，web.xml有contextLoaderListener监听器，spring等框架实现了本监听器的接口方法）
6. 调用完contextInitialized方法后，容器再对filter初始化
7. 容器对web.xml中的指定load-on-startup的值时，
   1. 当值为0或者大于0时，表示容器在应用启动时就加载并初始化这个servlet。
   2. 如果值小于0或未指定时，则表示只有在第一次请求的容器才在该servlet调用初始化函数(springMVC的初始化为此阶段。
   3. 正值越小，（优先级1,2,3…->递减）servlet的优先级越高，应用启动时就越先加载。
   4. 值相同时，容器就会自己选择顺序来加载。

ServletContext -> context-param（无顺序）-> listener（无顺序）-> filter（书写顺序） -> servlet（load-on-startup优先级）

web.xml文件中配置的< context-param >

< context-param >是上下文参数，< context-param >是application范围内的初始化参数，用于向servlet-context提供键值对，即应用程序的上下文信息，listener、filter等初始化时会用到这些信息

web.xml文件中配置的< DispatcherServlet >
< DispatcherServlet >是在我们第一次访问我们的应用的时候创建的。这时候它默认会将配置在/WEB-INF下面的< servlet-name >-servlet.xml配置文件，然后也创建一个WebApplicationContext。这个WebApplicationContext将之前ContextLoaderListener创建的容器作为父容器，因此在父容器中配置的所有Bean都能够被注入到子容器中。

6.spring中的配置文件的作用

于spring下的两个配置文件，applicationContext.xml以及spring-mvc.xml之间的区别以及到底有什么用处还是不太了解，后来我去查阅了一些信息，也大致明白了一些。

对于这两者：
applicationContext.xml

application-context.xml是全局的，应用于多个serverlet，配合listener一起使用，web.xml中配置如下：

    org.springframework.web.context.ContextLoaderListener


    contextConfigLocation
    classpath:applicationContext.xml

spring-mvc.xml
spring-mvc.xml 是spring mvc的配置，web.xml中配置如下：

  springMVC
  org.springframework.web.servlet.DispatcherServlet
  
    contextConfigLocation
    classpath:config/spring-mvc.xml
  
  1
  true

application-context.xml一般是采用非spring mvc架构，用来加载Application Context。
如果直接采用SpringMVC，只需要把所有相关配置放到spring-mvc.xml中就好，一般spring mvc项目用不到多个serverlet。

知识引用：
链接1：https://blog.csdn.net/truong/article/details/76213541
链接2：https://blog.csdn.net/carson0408/article/details/79019400
链接3：https://blog.csdn.net/shang_xue/article/details/79869151