引用spring的官方文档中的一段描述:html
在Spring2.0以前的版本中,@Repository
注解能够标记在任何的类上,用来代表该类是用来执行与数据库相关的操做(即dao对象),并支持自动处理数据库操做产生的异常前端
在Spring2.5版本中,引入了更多的Spring类注解:@Component
,@Service
,@Controller
。@Component
是一个通用的Spring容器管理的单例bean组件。而@Repository
, @Service
, @Controller
就是针对不一样的使用场景所采起的特定功能化的注解组件。java
所以,当你的一个类被@Component
所注解,那么就意味着一样能够用@Repository
, @Service
, @Controller
来替代它,同时这些注解会具有有更多的功能,并且功能各异。git
最后,若是你不知道要在项目的业务层采用@Service
仍是@Component
注解。那么,@Service
是一个更好的选择。github
就如上文所说的,@Repository
早已被支持了在你的持久层做为一个标记能够去自动处理数据库操做产生的异常(译者注:由于原生的java操做数据库所产生的异常只定义了几种,可是产生数据库异常的缘由却有不少种,这样对于数据库操做的报错排查形成了必定的影响;而Spring拓展了原生的持久层异常,针对不一样的产生缘由有了更多的异常进行描述。因此,在注解了@Repository
的类上若是数据库操做中抛出了异常,就能对其进行处理,转而抛出的是翻译后的spring专属数据库异常,方便咱们对异常进行排查处理)。spring
注解 | 含义 |
---|---|
@Component | 最普通的组件,能够被注入到spring容器进行管理 |
@Repository | 做用于持久层 |
@Service | 做用于业务逻辑层 |
@Controller | 做用于表现层(spring-mvc的注解) |
这几个注解几乎能够说是同样的:由于被这些注解修饰的类就会被Spring扫描到并注入到Spring的bean容器中。数据库
这里,有两个注解是不能被其余注解所互换的:spring-mvc
@Controller
注解的bean会被spring-mvc框架所使用。 @Repository
会被做为持久层操做(数据库)的bean来使用
若是想使用自定义的组件注解,那么只要在你定义的新注解中加上@Component便可:mvc
@Component
@Scope("prototype") public @interface ScheduleJob {...}
这样,全部被@ScheduleJob
注解的类就均可以注入到spring容器来进行管理。咱们所须要作的,就是写一些新的代码来处理这个自定义注解(译者注:能够用反射的方法),进而执行咱们想要执行的工做。框架
@Component
就是跟<bean>
同样,能够托管到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
层是业务逻辑层注解,这个注解只是标注该类处于业务逻辑层。
用这些注解对应用进行分层以后,就能将请求处理,义务逻辑处理,数据库操做处理分离出来,为代码解耦,也方便了之后项目的维护和开发。