【SpringMVC】常用注解

王彬泽

已于 2024-01-08 19:44:53 修改

阅读量800

点赞数 14

分类专栏： Spring系列文章标签： java Spring SpringMVC

于 2024-01-05 21:16:12 首次发布

本文链接：https://blog.csdn.net/weixin_73060900/article/details/135418066

版权

Spring系列专栏收录该内容

5 篇文章 0 订阅

订阅专栏

什么是MVC？MVC是一种程序分层开发模式，分别是Model（模型），View（视图）以及Controller（控制器）。这样做可以将程序的用户界面和业务逻辑分离，使得代码具有良好的可扩展性、可复用性、可维护性和灵活性。

@Controller

显而易见，@Controller注解对应的是MVC模式中的Controller对象。在Bean注解存储对象一文中也有过介绍，@Controller表示的是控制器，归属于业务逻辑层，对前端发来的请求进行判断，观察其数据是否合理，也就是控制用户行为，判断参数合理性。

使用位置：Java类上。

@RequestMapping

@RequestMapping，翻译过来的意思就是请求映射，顾名思义就是对前端发来的路由地址进行映射，使其对应到某个类或者方法上。

使用位置

1. Java类

如上图，若对应到某个类上，那么这个类其中的所有方法进行请求映射时都需要先把父路径加上。

2. Java方法

如上图，当用户想要进行登录的时候，前端就会向后端发一个路由，而路由正是根据这个@RequestMapping注解其中的请求映射而来。

常见属性

1. value

value指的就是请求地址，但是使用的时候一般其他属性不多见，因此也就将其直接省略。

@RequestMapping(value = "/login")

2. method

如果各位程序猿有了解过HTTP协议的话，这其实就是HTTP协议首行中的方法。本来设计协议的大佬是为了更好的描述一次请求是想要干啥，但是在实际开发中，好多都是一刀切，直接使用一个POST请求解决一切请求。

GET：获取资源，也就是CURD中的查询操作，将数据库中的一些资源给返回前端，然后前端调取显示到页面上；例如博客系统中可以使用GET请求来获取博客。
POST：添加资源/修改资源，较着重于添加资源，也就是CURD中的增加操作，给数据库中增加一些实例个体；例如写好一篇文章之后点击提交按钮就是发送POST请求将播客存储到数据库中。
DELETE：删除资源，也就是CURD中的删除操作，在数据库中删除一些信息；例如点击一篇博客的删除按钮就是发送DELETE请求将此篇博客删除。
PUT：修改资源，也就是CURD中的修改操作，将数据库中的一些信息进行修改；例如发现博客系统的一篇博客不太好，然后进行修改，再提交时就是使用PUT请求。
PATCH：新引入的一个方法，修改局部资源，还是修改操作，和PUT不太一样的是修改局部，其实我感觉还是比较鸡肋，毕竟有那么多还是POST一刀切，那为啥还要增加这种，不过从维护角度看还是非常不错，通过这些注解大概了解代码进行了啥操作。

上述最常用的就是GET和POST请求，在面试中也会问一些关于这两个操方法的不同点，需要切记的一点就是没有啥区别，毕竟都是人为规定的，那么肯定就是可以修改的。

@RequestMapping(value = "/login", method = RequestMethod.GET)

@PostMapping(value = "/login")

综上所述，@RequestMapping注解就是进行路由映射，也就是前端在进行某些操作时会用到一些数据，而这些数据存储在数据库中，此时前端就会发送路由，而后端根据发送的路由就可以映射到对应的类和方法上进行逻辑操作。

@ResponseBody

@ResponseBody，翻译过来的意思就是响应正文，也就是收到请求进行逻辑处理后给前端返回一个怎么样形式的数据，通常是XML或者是JSON格式的数据；并且这个数据返回时封装在HTTP请求的body中。

使用位置：类或者方法上，并且可以和@Controller注解合并成一个注解@RestController使用。

注意

在使用@RequestMapping之后，被认为是要进行路径跳转；但是加上@ResponseBody注解之后，就表示返回指定格式的数据，而不是进行页面跳转。

如上图所示案例，当没有@ResponseBody注解时，返回的就是一个页面，但是当加上注解之后，返回的就是一个数，而这个数据类型就是根据你写的类型进行返回；特别注意的是不加注解时只能返回text/html类型的。

上述四个案例分别抓包观察如下：

第一个案例不使用注解并且按照规定返回一个页面。

第二个案例使用注解返回一个字符串，请求自动响应为html类型。

第三个案例使用注解并且返回一个对象，请求自动响应为json类型。

第四个案例并未使用注解并且返回一个对象，但是未加注解的只能返回一个html页面，因而报错。

综上所述，@ResponseBody就是为了返回数据而存在；如果存在注解，那么返回数据的格式是多样的，但是如果没有这个注解，返回的Content-Type就只能是text/html的。

@Requestparam

@Requestparam，翻译过来就是请求参数。本质上写代码不使用这个注解也是没有问题的，但是为了代码的严谨性，建议叠加。

使用位置：如上图所示，使用位置在形参之前。

常见属性

1. value

表示的就是接收的参数名称，在上图中的"username"表示的就是value，和前端传来的key value中的key是一致的。

@RequestParam(value = "username") String username

2. required

表示某个参数是不是必须的，在源码中默认是true，所以加上注解之后，如果没有把此属性变成false那么就必须要传这个参数，否则就会报错。

(@RequestParam(value = "username", required = false)

3. defaultValue

表示给定参数一个默认值，若前端没有提供参数，那么就使用这个默认值。

(@RequestParam(value = "username", required = false, defaultValue = "赵四")

值得特别注意的是，由于@RequestParam的原理和Request.getParameter()类似，所以是通过key value来获取参数值的，这也就决定了它可以通过GET请求使用query String传参，也可以使用POST请求中的表单形式传参，如下图所示：

综上所述，@RequestParsm注解是表示请求参数的绑定，并且GET和POST请求都可以进行传参；此注解存在的意义就是为了和前端传来的数据保持一致性，例如前端传了一个创建时间但是名字直接为‘time’，理论是合法的，但是代码可识别度上不高，因此后端在使用注解接收之后自己再更名为createTime，这样就极大增加了可维护性。

在本篇文章中，主要介绍了四个注解的含义，基本作用等；后续的注解就在后续的文章中进行基本阐述和我自己的理解，希望各位喜欢。