springmvc01
|
springmvc01
|
|
|
线索Cues
|
笔记Notes
|
|
springmvc是现在开发web应用的框架。它负责处理请求和响应请求，springmvc的请求是很复杂的，如图所示:
 在请求离开浏览器时 ，会带有用户所请求内容的信息，至少会包含请求的URL。但是还可能 带有其他的信息，例如用户提交的表单信息。 请求旅程的第一站是Spring的DispatcherServlet。与大多数基于Java的Web框架一样， Spring MVC所有的请求都会通过一个前端控制器（front controller）Servlet。前端控制器是常用 的Web应用程序模式，在这里一个单实例的Servlet将请求委托给应用程序的其他组件来执行 实际的处理。在Spring MVC中，DispatcherServlet就是前端控制器。 DispatcherServlet的任务是将请求发送给Spring MVC控制器（controller）。控制器是一个 用于处理请求的Spring组件。在典型的应用程序中可能会有多个控制 器，DispatcherServlet需要知道应该将请求发送给哪个控制器。所以 DispatcherServlet以会查询一个或多个处理器映射（handler mapping） 来确定请求的下 一站在哪里。
处理器映射会根据请求所携带的URL信息来进行决策。 一旦选择了合适的控制器，DispatcherServlet会将请求发送给选中的控制器 。
到了控制 器，请求会卸下其负载（用户提交的信息）并耐心等待控制器处理这些信息。（实际上，设计良 好的控制器本身只处理很少甚至不处理工作，而是将业务逻辑委托给一个或多个服务对象进 行处理。） 控制器在完成逻辑处理后，通常会产生一些信息，这些信息需要返回给用户并在浏览器上显 示。这些信息被称为模型（model）。不过仅仅给用户返回原始的信息是不够的——这些信息需 要以用户友好的方式进行格式化，一般会是HTML。所以，信息需要发送给一个视图（view）， 通常会是JSP。
控制器所做的最后一件事就是将模型数据打包，并且标示出用于渲染输出的视图名。它接下 来会将请求连同模型和视图名发送回DispatcherServlet 。 这样，控制器就不会与特定的视图相耦合，传递给DispatcherServlet的视图名并不直接 表示某个特定的JSP。实际上，它甚至并不能确定视图就是JSP。相反，它仅仅传递了一个逻辑 名称，这个名字将会用来查找产生结果的真正视图。
DispatcherServlet将会使用视图解 析器（view resolver） 来将逻辑视图名匹配为一个特定的视图实现，它可能是也可能不是JSP。 既然DispatcherServlet已经知道由哪个视图渲染结果，那请求的任务基本上也就完成 了。它的最后一站是视图的实现（可能是JSP） ，在这里它交付模型数据。请求的任务就完成 了。视图将使用模型数据渲染输出，这个输出会通过响应对象传递给客户端（不会像听上去那 样硬编码） 。
在pom文件中导入依赖,spring中对于web分为两种一种是springweb一种是springmvc，springweb只提供了基础的http支持，mvc在web的基础上扩展了更多的功能，所以直接导入mvc即可
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>5.1.5.RELEASE</version>
</dependency>
DispatcherServlet的配置依然有两种，一种使用xml，一种使用代码的方式，首先新建一类继承AbstractAnnotationConfigDispatcherServletInitializer，例如:
 这个类会自动配置DispatcherServlet，意味着这个类就相当于xml中配置的DispatcherServlet。至于这个AbstractAnnotationConfigDispatcherServletInitializer实际上要从servlet3.0的机制讲起，servlet3.0会自动寻找实现ServletContainerInitializer这个类的实现类，并将其注入到servlet容器中，spring通过SpringServletContainerInitializer实现了这个类，并且通过@HandlesTypes注解将WebApplicationInitializer注入到onStartup中，总的来说，就是将实现了WebApplicationInitializer的类都注入的sevlet容器中。
 而在我们自己的 DispatcherServlet中继承的AbstractAnnotationConfigDispatcherServletInitializer 就继承与AbstractDispatcherServletInitializer
 而这个AbstractDispatcherServletInitializer继承与AbstractContextLoaderInitializer
 AbstractContextLoaderInitializer实现了WebApplicationInitializer
 最后得出我们的结论，只要实现了AbstractAnnotationConfigDispatcherServletInitializer就会被注入到servlet容器中。
回到我们新建的DispatcherServlet，我们发现有是哪个方法，其中一个是getRootConfigClasses，一个是getServletConfigClasses这两个加载不同的配置类，那么这两个又有什么区别呢，这又要从之前提到的servlet容器讲起，当一个web应用启动的时候，会触发容器的初始化事件，在这个过程中，以往spring容器都是我们主动创建的，在web应用中就是由这个监听事件初始化spring容器。spring会初始化一个上下文，即 WebApplicationContext，这是一个接口类，他对应的实现类就是spring的ioc容器，，并且将其存储到 ServletContext（上下文）中，之后会初始化web.xml中的servlet，因为我们使用的是实现AbstractAnnotationConfigDispatcherServletInitializer类的方式，所以我们也会被初始化，并且初始化之后会新建一个属于自己上下文，在这个过程中会把 ServletContext作为自己的父上下文， 初始化完毕后，spring以与servlet的名字相关(此处不是简单的以servlet名为Key，而是通过一些转换，具体可自行查看源码)的属性为属性Key，也将其存到ServletContext中，以便后续使用。这样每个servlet就持有自己的上下文，即拥有自己独立的bean空间，同时各个servlet共享相同的bean，即根上下文(第2步中初始化的上下文)定义的那些bean。
  在源码中我们可以看到，每次初始化，都会加载对应的上下文。所以getServletConfigClasses加载的就是mvc也就是 DispatcherServlet自己的上下文，而getRootConfigClasses就是其他我们自己建立的Bean。但是
首先新建一个配置类，在spring5.0之后需要实现WebMvcConfigurer接口，并且加上@EnableWebMvc以启用mvc。
 下图为配置的各种方法。
 紧接着配置RootConfig
 最后配置
 剩下的就可以编写Controll了
  |
|
总结Summary
|
|
|
|
|
@HandlesTypes
|
|
通过@HandlesTypes注入到 ServletContainerInitializerde的 onStartup方法中
|
|
@EnableWebMvc
|
|
启用mvc特性
|
|
@Controller
|
|
声明这个一个控制器类，实际作用和@Component注解一样，只是为了区分
|
|
@RequestMapping
|
@RequestMapping("/")
|
请求路径，参数是一个String类型的数组
|
|
@RequestParam
|
@RequestParam("")
|
从request里面拿取值
|
@PathVariable |
@RequestMapping(value="/{spittleId}",method=RequestMethod.GET)
@PathVariable("spittleId") long spittleId
|
这个注解能够识别URL里面的一个模板，我们看下面的一个URL
|
|
@NotEmpty
|
@NotEmpty(message = "课程id不能为空",groups = UpdateGroup.class)
|
被注释的字符串必须非空
|
|
@Length
|
@Length(min = 1,max=50 ,message = "课程名称为1-50个字符")
|
hibernate的注解，规定长度
|
|
@NotNull
|
|
被注释的属性非空
|
|
|
|
|
|
|
|
|
