SSM常见注解整理

声明：由于时间很久了，不知道参考的哪些博主的博文了，截图就是参考的博主的，这里表示抱歉。自己也稍微整理一下，供自己学习使用，如有错误请大佬们指正，谢谢！
作者：rookiequ

SSM常用的注解

1.@Component、@Repository、@Service以及@Controller之间的关系和区别

@Controller：作用于表现层（spring-mvc的注解），它注解的类进行前端请求的处理，转发，重定向。包括调用Service层的方法。

@Service：作用于业务逻辑层（service层）

@Repository：作用于持久层（dao层），它注解的类作为DAO对象（数据访问对象，Data Access Objects），这些类可以直接对数据库进行操作

@Component：是一个通用的Spring容器管理的单例bean组件，最普通的组件，可以被注入到spring容器进行管理。@Component是通用注解，其他三个注解是这个注解的拓展，并且具有了特定的功能。

@RequestMapping：是一个用来处理请求地址映射的注解，可用于类或方法上。用于类上，表示类中的所有响应请求的方法都是以该地址作为父路径。该注解有六个属性：

1、 value， method；
value：     指定请求的实际地址，指定的地址可以是URI Template 模式（后面将会说明）；
method：  指定请求的method类型， GET、POST、PUT、DELETE等；
2、 consumes，produces；
consumes： 指定处理请求的提交内容类型（Content-Type），例如application/json, text/html;
produces:    指定返回的内容类型，仅当request请求头中的(Accept)类型中包含该指定类型才返回；
3、 params，headers；
params： 指定request中必须包含某些参数值是，才让该方法处理。
headers： 指定request中必须包含某些指定的header值，才能让该方法处理请求。

Spring 4.3 引入了方法级注解的变体，也被叫做 @RequestMapping的组合注解。组合注解可以更好的表达被注解方法的语义。它们所扮演的角色就是针对 @RequestMapping 的封装，而且成了定义端点的标准方法。

例如，@GetMapping是一个组合注解，它所扮演的是 @RequestMapping(method =RequestMethod.GET) 的一个快捷方式。

方法级别的注解变体有如下几个：

• @GetMapping
• @PostMapping
• @PutMapping
• @DeleteMapping

2.@Mapper和**@MapperScan**的区别

@Mapper：作用是为了把mapper这个DAO交给Spring容器管理，目前的我的理解是将该注解放在dao层的接口上，对应了它的.xml的映射文件。一个接口，就要在接口上方加一个mapper注解。

@Mapper
public interface UserDAO {

    /**
     * 插入
     * @param userDO
     */
    public void insert(UserDO userDO);
}

@MapperScan：如上面所讲，当存在多个mapper接口时，在每个接口上方都要加一个@Mapper注解，这样显得十分的繁琐，为此我们可以直接在SpringBoot的启动类的上方加一个@MapperScan注解，来解决这个问题。此注解可以添加对包的的扫描，我们可以直接将mapper接口所在的包写在此注解里，这样就会自动扫描所有的mapper接口。

@SpringBootApplication
@MapperScan("com.lz.water.monitor.mapper")
// 添加对mapper包扫描
public class Application {
    public static void main(String[] args) {
    	SpringApplication.run(Application.class, args);
    }
}

3.@Autowired和@Resource的区别

@Resource：是用来实现依赖注入的，此注解是byName自动注入的

@Autowired：也是用来实现依赖注入的，但是此注解是byType自动注入的

注意：Spring容器以name为key储存bean！这里的name可以指定，否则取首字母小写的类名。有相同的就报异常：BeanDefinitionStoreException！

@Resource有两个常用属性name、type, Spring将name属性解析为bean的名字，而type属性则被解析为bean的类型。所以如果使用name属性，则使用byName的自动注入策略，如果使用type属性则使用byType的自动注入策略。如果都没有指定，则通过反射机制使用byName自动注入策略。

1.指定name和type：通过name找到唯一的bean，找不到抛出异常；如果type和字段类型不一致，也会抛出异常
2.指定name：通过name找到唯一的bean，找不到抛出异常
3.指定type：通过tpye找到唯一的bean，如果不唯一，则抛出异常：NoUniqueBeanDefinitionException
4.都不指定：通过字段名作为key去查找，找到则赋值；找不到则再通过字段类型去查找，如果不唯一，则抛出异常：NoUniqueBeanDefinitionException

@Autowired只有一个属性required，默认值为true，为true时，找不到就抛异常，为false时，找不到就赋值为null

@Autowired按类型查找，如果该类型的bean不唯一，则抛出异常；可通过组合注解解决

@Autowired
@Qualifier("baseDao")

@Autowired和@Resource的共同点是：

• 1.Spring都支持

• 2.都作用在字段和setter方法上

@Autowired和@Resource的不同点是：

• 1.Resource是JDK提供的，而Autowired是Spring提供的
• 2.Resource不允许找不到bean的情况，而Autowired允许（@Autowired(required = false)）
• 3·指定name的方式不一样，@Resource(name = "baseDao"),@Autowired()和@Qualifier("baseDao")
• 4·Resource默认通过name查找，而Autowired默认通过type查找

4.@RequestBody和@RequestParame的区别

@RequestParame：注解@RequestParam接收的参数是来自requestHeader中，即请求头。@RequestParam可以接受简单类型的属性，也可以接受对象类型。@RequestParam有三个配置参数如下：

1.required 表示是否必须，默认为 true，必须。
2.defaultValue 可设置请求参数的默认值。
3.value 为接收url的参数名（相当于key值）。

@RequestParam用来处理 Content-Type 为 application/x-www-form-urlencoded 编码的内容，Content-Type默认为该属性。@RequestParam也可用于其它类型的请求，例如：POST、DELETE等请求。所以在postman中，要选择body的类型为 x-www-form-urlencoded，这样在headers中就自动变为了 Content-Type : application/x-www-form-urlencoded 编码格式。如下图所示：

但是这样不支持批量插入数据啊，如果改用 json 字符串来传值的话，类型设置为 application/json，点击发送的话，会报错，后台接收不到值，为 null。这个时候@RequestBody就派上用场了

@RequestBody：注解@RequestBody接收的参数是来自requestBody中，即请求体。一般用于处理非 Content-Type: application/x-www-form-urlencoded编码格式的数据，比如：application/json、application/xml等类型的数据。就application/json类型的数据而言，使用注解@RequestBody可以将body里面所有的json数据传到后端，后端再进行解析。

由于@RequestBody可用来处理 Content-Type 为 application/json 编码的内容，所以在postman中，选择body的类型为raw -> JSON(application/json)，这样在 Headers 中也会自动变为 Content-Type: application/json 编码格式。body内的数据如下图所示：

上面要注意的是json里的key值要和后端的实体类的属性一一对应。

注意：前端使用$.ajax的话，一定要指定 contentType: "application/json;charset=utf-8;"，默认为 application/x-www-form-urlencoded。当后端没有实体类与前端的json数据相对应时，我们可以通过在后端用map参数或者map集合来接受前端传来的json数据。

@RequestBody可以解析Body中json格式的数据。

POST请求时：

@RequestBody–> JSON字符串部分

@RequestParam–> 请求参数部分

1、从content-type方面总结：
① form-data、x-www-form-urlencoded：不可以用@RequestBody；可以用@RequestParam。见postman的格局，这两种方式的时候没有json字符串部分。

② application/json：json字符串部分可以用@RequestBody；url中的?后面参数可以用@RequestParam。见postman的格局
2、从两种注解方式总结:

@RequestBody

(@RequestBody Map map)
(@RequestBody Object object)
application/json时候可用
form-data、x-www-form-urlencoded时候不可用

@RequestParam

(@RequestParam Map map)
application/json时候，json字符串部分不可用，url中的?后面添加参数即可用，form-data、x-www-form-urlencoded时候可用，但是要将Headers里的Content-Type删掉

------------------------------------------

(@RequestParam String waterEleId,@RequestParam String enterpriseName)
application/json时候，json字符串部分不可用，url中的?后面添加参数即可用
form-data、x-www-form-urlencoded时候可用，且参数可以没有顺序（即前端传过来的参数或者url中的参数顺序不必和后台接口中的参数顺序一致，只要字段名相同就可以），但是要将Headers里的Content-Type删掉

------------------------------------------

(@RequestParam Object object)
不管application/json、form-data、x-www-form-urlencoded都不可用

既不是@RequestBody也不是@RequestParam，没有指定参数哪种接收方式

(Map map)
(Object object)
application/json时候：json字符串部分不可用，url中的?后面添加参数不可用。
因为没有指定，它也不知道到底是用json字符串部分还是?后面添加参数部分，所以干脆都不可以用
form-data、x-www-form-urlencoded时都不可用，见图二
 
(HttpServletRequest request)
application/json不可用
form-data、x-www-form-urlencoded时可用

GET请求时：

@RequestBody

RequestBody -- Map / Object
GET请求中不可以使用@RequestBody

@RequestParam

(@RequestParam Map map)
在url中的?后面添加参数即可使用

---------------------------------

(@RequestParam String waterEleId,@RequestParam String enterpriseName)
在url中的?后面添加参数即可使用

---------------------------------

(@RequestParam Object object)
GET请求中不可以使用

总结：

•在GET请求中，不能使用@RequestBody。

•在POST请求，可以使用@RequestBody和@RequestParam，但是如果使用@RequestBody，对于参数转化的配置必须统一。
可以使用多个@RequestParam获取数据，@RequestBody不可以（它只能有一个） 。举个例子，在SpringMVC配置了HttpMessageConverters处理栈中，指定json转化的格式，如Date转成‘yyyy-MM-dd’,则参数接收对象包含的字段如果是Date类型，就只能让客户端传递年月日的格式，不能传时分秒。因为不同的接口，它的参数可能对时间参数有不同的格式要求，所以这样做会让客户端调用同事对参数的格式有点困惑，所以说扩展性不高。 如果使用@RequestParam来接受参数，可以在接受参数的model中设置@DateFormat指定所需要接受时间参数的格式。 另外，使用@RequestBody接受的参数是不会被Servlet转化统一放在request对象的Param参数集中，@RequestParam是可以的。

另外，还有一种应用场景，接口规范为resultful风格时，举个例子：如果要获取某个id下此条问题答案的查询次数的话，则后台就需要动态获取参数，其注解为@PathVariable，并且@RequestMapping中的value应为value="/{id}/queryNum"，截图如下：