springboot项目怎么添加RestController注解

@Resource和@Autowired的区别

Spring不但支持自己定义的@Autowired注解，还支持由JSR-250规范定义的几个注解。如：@Resource、@PostConstruct及@PreDestroy

1、@Autowired

由Spring提供，只按照byType注入

2、@Resource

由J2EE提供，默认按照byName自动注入

@Resource有两个重要的属性：name和type

Spring将@Resource注解的name属性解析为bean的名字，type属性则解析为bean的类型。所以如果使用name属性，则使用byName的自动注入策略，而使用type属性则使用byType自动注入策略。如果既不指定name也不指定type属性，这时将通过反射机制使用byName自动注入策略。

@Resource装配顺序：

（1）如果同时指定了name和type，则从Spring上下文中找到唯一匹配的bean进行装配，找不到则抛出异常

（2）如果指定了name，则从Spring上下文中查找名称（id）匹配的bean进行装配，找不到则抛出异常

（3）如果指定了type，则从Spring上下文中找到类型匹配的唯一bean进行装配，找不到或找到多个，都抛出异常

（4）如果既没指定name，也没指定type,则自动按照byName方式进行装配。如果没有匹配，则回退为一个原始类型进行匹配，如果匹配则自动装配。

@Resource的作用相当于@Autowired，只不过@Autowired按byType自动注入。

3、使用区别

（1）@Autowired与@Resource都可以用来装配bean，都可以写在字段或setter方法上

（2）@Autowired默认按类型装配，默认情况下必须要求依赖对象存在，如果要允许null值，可以设置它的required属性为false。如果想使用名称装配可以结合@Qualifier注解进行使用。

（3）@Resource，默认按照名称进行装配，名称可以通过name属性进行指定，如果没有指定name属性，当注解写在字段上时，默认取字段名进行名称查找。如果注解写在setter方法上默认取属性名进行装配。当找不到与名称匹配的bean时才按照类型进行装配。但是需要注意的是，如果name属性一旦指定，就只会按照名称进行装配。

推荐使用@Resource注解在字段上，这样就不用写setter方法了，并且这个注解是属于J2EE的，减少了与Spring的耦合。

@Component, @Repository, @Service的区别

官网引用
引用spring的官方文档中的一段描述：

在Spring2.0之前的版本中，@Repository注解可以标记在任何的类上，用来表明该类是用来执行与数据库相关的操作（即dao对象），并支持自动处理数据库操作产生的异常

在Spring2.5版本中，引入了更多的Spring类注解：@Component,@Service,@Controller。@Component是一个通用的Spring容器管理的单例bean组件。而@Repository, @Service, @Controller就是针对不同的使用场景所采取的特定功能化的注解组件。

因此，当你的一个类被@Component所注解，那么就意味着同样可以用@Repository, @Service, @Controller来替代它，同时这些注解会具备有更多的功能，而且功能各异。

最后，如果你不知道要在项目的业务层采用@Service还是@Component注解。那么，@Service是一个更好的选择。

就如上文所说的，@Repository早已被支持了在你的持久层作为一个标记可以去自动处理数据库操作产生的异常（译者注：因为原生的java操作数据库所产生的异常只定义了几种，但是产生数据库异常的原因却有很多种，这样对于数据库操作的报错排查造成了一定的影响；而Spring拓展了原生的持久层异常，针对不同的产生原因有了更多的异常进行描述。所以，在注解了@Repository的类上如果数据库操作中抛出了异常，就能对其进行处理，转而抛出的是翻译后的spring专属数据库异常，方便我们对异常进行排查处理）。

注解 含义
@Component 最普通的组件，可以被注入到spring容器进行管理
@Repository 作用于持久层
@Service 作用于业务逻辑层
@Controller 作用于表现层（spring-mvc的注解）

其他网上资料
这几个注解几乎可以说是一样的：因为被这些注解修饰的类就会被Spring扫描到并注入到Spring的bean容器中。

这里，有两个注解是不能被其他注解所互换的：

@Controller 注解的bean会被spring-mvc框架所使用。
@Repository 会被作为持久层操作（数据库）的bean来使用
如果想使用自定义的组件注解，那么只要在你定义的新注解中加上@Component即可：

@Component
@Scope(“prototype”)
public @interface ScheduleJob {…}

这样，所有被@ScheduleJob注解的类就都可以注入到spring容器来进行管理。我们所需要做的，就是写一些新的代码来处理这个自定义注解（译者注：可以用反射的方法），进而执行我们想要执行的工作。

@Component就是跟一样，可以托管到Spring容器进行管理。

@Service, @Controller , @Repository = {@Component + 一些特定的功能}。这个就意味着这些注解在部分功能上是一样的。

当然，下面三个注解被用于为我们的应用进行分层：

@Controller注解类进行前端请求的处理，转发，重定向。包括调用Service层的方法
@Service注解类处理业务逻辑
@Repository注解类作为DAO对象（数据访问对象，Data Access Objects），这些类可以直接对数据库进行操作
有这些分层操作的话，代码之间就实现了松耦合，代码之间的调用也清晰明朗，便于项目的管理；假想一下，如果只用@Controller注解，那么所有的请求转发，业务处理，数据库操作代码都糅合在一个地方，那这样的代码该有多难拓展和维护。

总结
@Component, @Service, @Controller, @Repository是spring注解，注解后可以被spring框架所扫描并注入到spring容器来进行管理
@Component是通用注解，其他三个注解是这个注解的拓展，并且具有了特定的功能
@Repository注解在持久层中，具有将数据库操作抛出的原生异常翻译转化为spring的持久层异常的功能。
@Controller层是spring-mvc的注解，具有将请求进行转发，重定向的功能。
@Service层是业务逻辑层注解，这个注解只是标注该类处于业务逻辑层。
用这些注解对应用进行分层之后，就能将请求处理，义务逻辑处理，数据库操作处理分离出来，为代码解耦，也方便了以后项目的维护和开发。

Dao层，Mapper层，controller层，service层，model层都有什么作用

SSM是sping+springMVC+mybatis集成的框架。
MVC即model view controller。

model层=entity层。
存放我们的实体类，与数据库中的属性值基本保持一致。

service层。
存放业务逻辑处理，也是一些关于数据库处理的操作，但不是直接和数据库打交道，他有接口还有接口的实现方法，在接口的实现方法中需要导入mapper层，mapper层是直接跟数据库打交道的，他也是个接口，只有方法名字，具体实现在mapper.xml文件里，service是供我们使用的方法。

在实际开发中的Service层可能被处理为实体Service层，而不是接口，业务逻辑直接写在Service（Class，不是Interface）层中，Controller直接调用Service，Service调用Mapper。
当然了，Service之间也是可以互相调用！

mapper层=dao层
现在用mybatis逆向工程生成的mapper层，其实就是dao层。对数据库进行数据持久化操作，他的方法语句是直接针对数据库操作的，而service层是针对我们controller，也就是针对我们使用者。service的impl是把mapper和service进行整合的文件。

（多说一句，数据持久化操作就是指，把数据放到持久化的介质中，同时提供增删改查操作，比如数据通过hibernate插入到数据库中。）

controller层。
控制器，导入service层，因为service中的方法是我们使用到的，controller通过接收前端传过来的参数进行业务操作，在返回一个指定的路径或者数据表。

Spring Boot MyBatis注解：@MapperScan和@Mapper

最近参与公司的新项目架构搭建，在使用mybatis的注解时，和同时有了不同意见，同事认为使用@Mapper注解简单明了，而我建议使用@MapperScan，直接将mapper所在的目录扫描进去就行，而且@Mapper需要在每一个mapper上都添加，繁琐。同事又说–我们可以用逆向工程自动生产entity，mapper，service时，将注解加上，很方便的，于是各执一词。

下面是我整理的这两种方法的比较：

使用@Mapper注解
　　为了让DemoMapper能够让别的类进行引用，我们可以在DemMapper类上添加@Mapper注解：

@Mapper 
public interface DemoMapper { 
@Insert("insert into Demo(name) values(#{name})") @Options(keyProperty="id",keyColumn="id",useGeneratedKeys=true) 
public void save(Demo demo); }

直接在Mapper类上面添加注解@Mapper，但是这种方式要求每一个mapper类都需要添加此注解，麻烦。

使用@MapperScan注解
　　通过使用@MapperScan可以指定要扫描的Mapper类的包的路径，比如：
复制代码
@SpringBootApplication 
@MapperScan("com.kfit.*.mapper") 
public class App { 
　　public static void main(String[] args) { 
　　　　SpringApplication.run(App.class, args); 
　　} 
}

使用@MapperScan注解多个包
　　可以使用如下的方式指定多个包： 

复制代码
@SpringBootApplication @MapperScan({"com.kfit.demo","com.kfit.user"}) 
public class App {
    public static void main(String[] args) { 
        SpringApplication.run(App.class, args); 
    } 
}

@Mapper 和@Repository

相同点
两个都是注解在Dao上

回到顶部
不同
@Repository需要在Spring中配置扫描地址，然后生成Dao层的Bean才能被注入到Service层中。

@Mapper不需要配置扫描地址，通过xml里面的namespace里面的接口地址，生成了Bean后注入到Service层中。

Intellij IDEA如何去掉@Autowired 注入警告的方法

问题

在Service层注入Mybatis的Mapper我们通常会使用@Autowired 自动注入

@Autowired
private ProductMapper productMapper;

但是这样Intellij IDEA会显示红色告警，提示不能自动注入。

当我们在Controller层注入Service时我们也经常直接在Filed上使用@Autowired 注解，这时候不显示红色警告，但是也显示Field injection is not recommended 的建议

原因

第一种情况是因为IDEA可以识别并理解Spring的上下文。然而Mapper接口是Mybatis的，IDEA理解不了。所以会出现红色告警。

而第二种原因是因为官方不推荐使用Filed进行注解，而推荐使用构造器或Setter方法进行注解，像下面两种写法就不会出现警告。

private final ProductService productService;
@Autowired
public ProductController(ProductService productService) {
    this.productService = productService;
}

or

private ProductService productService;
@Autowired
public void setProductService(ProductService productService) {
    this.productService = productService;
}

问题是什么

Field注入看起来非常好，够简洁，代码通俗易懂。你的类可以专注于业务而不被依赖注入所污染。你只需要把@Autowired扔到变量之上就好了，不需要特殊的构造器或者set方法，依赖注入容器会提供你所需的依赖。但是Field注入会带来2个问题：

当注入的对象依赖其他对象，而被依赖的对象没被创建的话就会出现空指针异常。
这样的类没办法在容器之外被重用，也不能期望反射提供其所需的依赖。
详细原因大家可以去这篇文章查看：http://olivergierke.de/2013/11/why-field-injection-is-evil/

构造器注入 VS Setter注入

Setter应该被用来注入可变的依赖。当没有提供依赖时，这个类也应该能够运转。当实例化对象后，这些依赖也能随时改变。其实也视情况而变,有时，一个不变的对象是理想状态。有时，最好是能在运行期间改变对象的属性。

构造器注入对象需要依赖的对象初始化后才能正常运转，通过构造器提供这些依赖就能保证对象初始化后就能被使用。使用构造器注入的一个可能的影响就是循环依赖。

怎么解决

我们可以使用Lombok提供的注解 @RequiredArgsConstructor 来解决这两个问题（Lombok这个大家项目都会使用吧）

@Service
@Log4j2
@RequiredArgsConstructor(onConstructor = @__(@Autowired))
public class ProductServiceImpl implements ProductService {
  private final ProductMapper productMapper;
    ...
}

这里必须使用final修饰符来修饰注入的Service或Mapper首先我们看看编译后的类是什么样

编译完成后变成了使用构造器进行注入

认识@RequiredArgsConstructor

Lombok官方给出的解释是: Generates constructor that takes one argument per final / non-null field. 所以它会为final和nonnull的属性作为参数产生一个构造函数。

而上面我们讲了Spring推荐使用Setter或构造器注入，那么@RequiredArgsConstructor刚好可以完成这件事，而且还简化了你的代码，何乐而不为是不是？