聊聊@Repository、@Component、@Controller、@Service有什么区别

总结
Scope的prototype与singleton区别

继《聊聊Spring家族中的那几百个注解》之后，我们来谈谈@Repository、@Component、@Controller、@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 能够扫描类路径中的类并识别出 @Repository 注解，需要在 XML 配置文件中启用Bean 的自动扫描功能，这可以通过context:component-scan/实现。如下所示：

` // 首先使用 @Repository 将 DAO 类声明为 Bean  package bookstore.dao;  @Repository  public class UserDaoImpl implements UserDao{ …… }   // 其次，在 XML 配置文件中启动 Spring 的自动扫描功能      ……   ……  `

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

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

@Controller 注解的bean会被spring-mvc框架所使用。
@Repository 会被作为持久层操作（数据库）的bean来使用

如果想使用自定义的组件注解，那么只要在你定义的新注解中加上@Component即可：

1
2
3

@Component 
@Scope("prototype")
public @interface ScheduleJob {...}

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

如果你想提供一个自定义的作用域解析策略而不使用基于注解的方法，只需实现 ScopeMetadataResolver接口，确认包含一个默认的没有参数的构造方法。然后在配置扫描器时提供全限定类名：

1	<context:component-scan base-package="a.b" scope-resolver="footmark.SimpleScopeResolver" />

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

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

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

@Controller注解类进行前端请求的处理，转发，重定向。包括调用Service层的方法
@Service注解类处理业务逻辑
@Repository注解类作为DAO对象（数据访问对象，Data Access Objects），这些类可以直接对数据库进行操作

有这些分层操作的话，代码之间就实现了松耦合，代码之间的调用也清晰明朗，便于项目的管理；假想一下，如果只用@Controller注解，那么所有的请求转发，业务处理，数据库操作代码都糅合在一个地方，那这样的代码该有多难拓展和维护。

总结

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

Scope的prototype与singleton区别

1 2	<bean class="com.****.boss.domain.utils.CacheManager" scope="singleton" init-method="init" destroy-method="destory"> </bean>

1
2
3

<bean id="messageProcessService" class="com.****.boss.domain.common.service.MessageProcessService" scope="prototype">
         <property name="orderHandleConfigService" ref="orderHandleConfigService" />
</bean>

1、singleton作用域
　　当一个bean的作用域设置为singleton, 那么Spring IOC容器中只会存在一个共享的bean实例，并且所有对bean的请求，只要id与该bean定义相匹配，则只会返回bean的同一实例。换言之，当把一个bean定义设置为singleton作用域时，Spring IOC容器只会创建该bean定义的唯一实例。这个单一实例会被存储到单例缓存（singleton cache）中，并且所有针对该bean的后续请求和引用都将返回被缓存的对象实例，这里要注意的是singleton作用域和GOF设计模式中的单例是完全不同的，单例设计模式表示一个ClassLoader中只有一个class存在，而这里的singleton则表示一个容器对应一个bean，也就是说当一个bean被标识为singleton时候，spring的IOC容器中只会存在一个该bean。

2、prototype
　　prototype作用域部署的bean，每一次请求（将其注入到另一个bean中，或者以程序的方式调用容器的getBean()方法）都会产生一个新的bean实例，相当与一个new的操作，对于prototype作用域的bean，有一点非常重要，那就是Spring不能对一个prototype bean的整个生命周期负责，容器在初始化、配置、装饰或者是装配完一个prototype实例后，将它交给客户端，随后就对该prototype实例不闻不问了。不管何种作用域，容器都会调用所有对象的初始化生命周期回调方法，而对prototype而言，任何配置好的析构生命周期回调方法都将不会被调用。清除prototype作用域的对象并释放任何prototype bean所持有的昂贵资源，都是客户端代码的职责。（让Spring容器释放被singleton作用域bean占用资源的一种可行方式是，通过使用bean的后置处理器，该处理器持有要被清除的bean的引用。）

scope=”prototype”没写的问题,项目中对一个表的增删该操作是用一个action，这个 actionadd,update,delete,save这些方法，添加和修改是共用一个页面，当页面得到id时代表进行的修改操作，反之是添加操作。因为在配置spring的bean是忘了写scope=”prototype” 所以每次添加时都显示最后一次访问过的记录,scope=”prototype” 会在该类型的对象被请求时创建一个新的action对象。如果没有配置scope=prototype则添加的时候不会新建一个action，他任然会保留上次访问的过记录的信息 webwork的Action不是线程安全的，要求在多线程环境下必须是一个线程对应一个独立的实例，不能使用singleton。所以，我们在Spring配置Webwork Action Bean时，需要加上属性scope=prototype”或singleton=”false”。
　　singleton模式指的是对某个对象的完全共享，包括代码空间和数据空间，说白了，如果一个类是singleton的，假如这个类有成员变量，那么这个成员变量的值是各个线程共享的（有点类似于static的样子了），当线程A往给变量赋了一个值以后，线程B就能读出这个值。因此，对于前台Action，肯定不能使用singleton的模式，必须是一个线程请求对应一个独立的实例。推而广之，只要是带数据成员变量的类，为了防止多个线程混用数据，就不能使用singleton。对于我们用到的Service、Dao，之所以用了singleton，就是因为他们没有用到数据成员变量，如果谁的Service需要数据成员变量，请设置singleton=false。有状态的bean都使用Prototype作用域，而对无状态的bean则应该使用singleton作用域。

简单的说：

singleton 只有一个实例，也即是单例模式。
prototype访问一次创建一个实例，相当于new。

应用场合：

需要回收重要资源(数据库连接等)的事宜配置为singleton，如果配置为prototype需要应用确保资源正常回收。
有状态的Bean配置成singleton会引发未知问题，可以考虑配置为prototype。

聊聊@Repository、@Component、@Controller、@Service有什么区别

总结

Scope的prototype与singleton区别

相关文章