Spring MVC框架入门

最新推荐文章于 2024-08-17 14:33:30 发布

挖野菜

最新推荐文章于 2024-08-17 14:33:30 发布

阅读量588

点赞数 2

分类专栏： Java 开发框架

本文链接：https://blog.csdn.net/Bonport/article/details/105112471

版权

Java 开发框架专栏收录该内容

25 篇文章 3 订阅

订阅专栏

在这里插入图片描述

文章目录

Spring MVC 角色划分清晰，分工明细，并且和 Spring 框架无缝结合。作为当今业界最主流的 Web 开发框架，Spring MVC 已经成为当前最热门的开发技能，同时也广泛用于桌面开发领域。

MVC设计模式简介

MVC 设计不仅限于 Java Web 应用，还包括许多应用，比如前端、PHP、.NET 等语言。之所以那么做的根本原因在于解耦各个模块。

MVC 是 Model、View 和 Controller 的缩写，分别代表 Web 应用程序中的 3 种职责。

模型：用于存储数据以及处理用户请求的业务逻辑。
视图：向控制器提交数据，显示模型中的数据。
控制器：根据视图提出的请求判断将请求和数据交给哪个模型处理，将处理后的有关结果交给哪个视图更新显示。

基于 Servlet 的 MVC 模式的具体实现如下。

模型：一个或多个 JavaBean 对象，用于存储数据（实体模型，由 JavaBean 类创建）和处理业务逻辑（业务模型，由一般的 Java 类创建）。
视图：一个或多个 JSP 页面，向控制器提交数据和为模型提供数据显示，JSP 页面主要使用 HTML 标记和 JavaBean 标记来显示数据。
控制器：一个或多个 Servlet 对象，根据视图提交的请求进行控制，即将请求转发给处理业务逻辑的 JavaBean，并将处理结果存放到实体模型 JavaBean 中，输出给视图显示。
基于 Servlet 的 MVC 模式的流程如图 1 所示。

Spring MVC框架搭建

https://blog.csdn.net/Bonport/article/details/105113035

Spring MVC处理用户请求的完整流程

Spring MVC 框架并不关心使用的视图技术，也不会强迫开发者只使用 JSP 技术，但教程中使用的视图是 JSP，本节主要介绍 Spring MVC 框架处理用户请求的完整流程和处理中包含的 4 个接口。

Spring MVC 工作流程
Spring MVC 框架主要由 DispatcherServlet、处理器映射、控制器、视图解析器、视图组成，其工作原理如图 1 所示。
在这里插入图片描述
从图 1 可总结出 Spring MVC 的工作流程如下：

客户端请求提交到 DispatcherServlet。
由 DispatcherServlet 控制器寻找一个或多个 - HandlerMapping，找到处理请求的 Controller。
DispatcherServlet 将请求提交到 Controller。
Controller 调用业务逻辑处理后返回 ModelAndView。
DispatcherServlet 寻找一个或多个 ViewResolver 视图解析器，找到 ModelAndView 指定的视图。
视图负责将结果显示到客户端。

Spring MVC接口

在图 1 中包含 4 个 Spring MVC 接口，即 DispatcherServlet、HandlerMapping、Controller 和 ViewResolver。

Spring MVC 所有的请求都经过 DispatcherServlet 来统一分发，在 DispatcherServlet 将请求分发给 Controller 之前需要借助 Spring MVC 提供的 HandlerMapping 定位到具体的 Controller。

HandlerMapping 接口负责完成客户请求到 Controller 映射。

Controller 接口将处理用户请求，这和 Java Servlet 扮演的角色是一致的。一旦 Controller 处理完用户请求，将返回 ModelAndView 对象给 DispatcherServlet 前端控制器，ModelAndView 中包含了模型（Model）和视图（View）。

从宏观角度考虑，DispatcherServlet 是整个 Web 应用的控制器；从微观考虑，Controller 是单个 Http 请求处理过程中的控制器，而 ModelAndView 是 Http 请求过程中返回的模型（Model）和视图（View）。

ViewResolver 接口（视图解析器）在 Web 应用中负责查找 View 对象，从而将相应结果渲染给客户。

视图解析器

Spring 视图解析器是 Spring MVC 中的重要组成部分，用户可以在配置文件中定义 Spring MVC 的一个视图解析器（ViewResolver），示例代码如下：

<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver" >
    <!--前缀-->
    <property name="prefix" value="/WEB-INF/jsp/"/>
    <!--后缀-->
    <property name="suffix" value=".jsp"/>
</bean>

上述视图解析器配置了前缀和后缀两个属性，因此《Spring MVC框架搭建》教程中的 RegisterController 和 LoginController 控制器类的视图路径仅需提供 register 和 login，视图解析器将会自动添加前缀和后缀。

InternalResourceViewResolver 是 URLBasedViewResolver 的子类，所以 URLBasedViewResolver 支持的特性它都支持。

在实际应用中 InternalResourceViewResolver 也是使用的最广泛的一个视图解析器。那么InternalResourceViewResolver有什么自己独有的特性呢？

单从字面意思来看，我们可以把 InternalResourceViewResolver 解释为内部资源视图解析器，这就是 InternalResourceViewResolver 的一个特性。

InternalResourceViewResolver 会把返回的视图名称都解析为 InternalResourceView 对象，InternalResourceView 会把 Controller 处理器方法返回的模型属性都存放到对应的 request 属性中，然后通过 RequestDispatcher 在服务器端把请求 forword 重定向到目标 URL。

比如在 InternalResourceViewResolver 中定义了 prefix=/WEB-INF/，suffix=.jsp，然后请求的 Controller 处理器方法返回的视图名称为 login，那么这个时候 InternalResourceViewResolver 就会把 login 解析为一个 InternalResourceView 对象，先把返回的模型属性都存放到对应的 HttpServletRequest 属性中，然后利用 RequestDispatcher 在服务器端把请求 forword 到 /WEB-INF/test.jsp。

这就是 InternalResourceViewResolver 一个非常重要的特性，我们都知道存放在 /WEB-INF/ 下面的内容是不能直接通过 request 请求的方式请求到的，为了安全性考虑，我们通常会把 jsp 文件放在 WEB-INF 目录下，而 InternalResourceView 在服务器端跳转的方式可以很好的解决这个问题。

Spring MVC获取请求参数方式&注解

@Controller和@RequestMapping，@Autowired和@Service注解，@ModelAttribute注解，
Spring MVC获取参数的几种常见方式：

https://blog.csdn.net/Bonport/article/details/105114771

Spring MVC的转发与重定向

重定向是将用户从当前处理请求定向到另一个视图（例如 JSP）或处理请求，以前的请求（request）中存放的信息全部失效，并进入一个新的 request 作用域；转发是将用户对当前处理的请求转发给另一个视图或处理请求，以前的 request 中存放的信息不会失效。

转发是服务器行为，重定向是客户端行为。
1）转发过程
客户浏览器发送 http 请求，Web 服务器接受此请求，调用内部的一个方法在容器内部完成请求处理和转发动作，将目标资源发送给客户；在这里转发的路径必须是同一个 Web 容器下的 URL，其不能转向到其他的 Web 路径上，中间传递的是自己的容器内的 request。

在客户浏览器的地址栏中显示的仍然是其第一次访问的路径，也就是说客户是感觉不到服务器做了转发的。转发行为是浏览器只做了一次访问请求。
2）重定向过程
客户浏览器发送 http 请求，Web 服务器接受后发送 302 状态码响应及对应新的 location 给客户浏览器，客户浏览器发现是 302 响应，则自动再发送一个新的 http 请求，请求 URL 是新的 location 地址，服务器根据此请求寻找资源并发送给客户。

在这里 location 可以重定向到任意 URL，既然是浏览器重新发出了请求，那么就没有什么 request 传递的概念了。在客户浏览器的地址栏中显示的是其重定向的路径，客户可以观察到地址的变化。重定向行为是浏览器做了至少两次的访问请求。

在 Spring MVC 框架中，控制器类中处理方法的 return 语句默认就是转发实现，只不过实现的是转发到视图。示例代码如下：

@RequestMapping("/register")
public String register() {
    return "register";  //转发到register.jsp
}

在 Spring MVC 框架中，重定向与转发的示例代码如下：

package controller;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
@Controller
@RequestMapping("/index")
public class IndexController {
    @RequestMapping("/login")
    public String login() {
        //转发到一个请求方法（同一个控制器类可以省略/index/）
        return "forward:/index/isLogin";
    }
    @RequestMapping("/isLogin")
    public String isLogin() {
        //重定向到一个请求方法
        return "redirect:/index/isRegister";
    }
    @RequestMapping("/isRegister")
    public String isRegister() {
        //转发到一个视图
        return "register";
    }
}

在 Spring MVC 框架中，不管是重定向或转发，都需要符合视图解析器的配置，如果直接转发到一个不需要 DispatcherServlet 的资源，例如：

return "forward:/html/my.html";

则需要使用 mvc：resources 配置：

<mvc:resources location="/html/" mapping="/html/**" />

请求参数类型转换

对于 Spring MVC 框架而言，它必须将请求参数转换成值对象类中各属性对应的数据类型。
类型转换是在视图与控制器相互传递数据时发生的。Spring MVC 框架对于基本类型（例如 int、long、float、double、boolean 以及 char 等）已经做好了基本类型转换。
在 Web 应用中由 HTTP 发送的请求数据到控制器中都是以 String 类型获取，因此在 Web 应用中选择 Formatter 比选择 Converter<S，T> 更加合理。

Converter（类型转换器）,Formatter（数据格式化）,JSON 数据转换详解: