@Component、@Repository和@Service注释是否可以在Spring中互换使用,或者它们除了充当符号设备之外,是否提供任何特定功能?
换句话说,如果我有一个Service类,并且我将注释从@Service更改为@Component,它的行为是否仍然相同?
或者注释是否也会影响类的行为和功能?
@Component、@Repository和@Service注释是否可以在Spring中互换使用,或者它们除了充当符号设备之外,是否提供任何特定功能?
换句话说,如果我有一个Service类,并且我将注释从@Service更改为@Component,它的行为是否仍然相同?
或者注释是否也会影响类的行为和功能?
当前回答
它们几乎相同——所有这些都意味着这个类是一个Spring bean@Service、@Repository和@Controller是专门的@Components。您可以选择与他们一起执行特定操作。例如:
@springmvc使用控制器bean@存储库bean有资格进行持久性异常转换
另一件事是将组件语义上指定给不同的层。
@Component提供的一点是,您可以用它注释其他注释,然后以与@Service相同的方式使用它们。
例如,最近我做了:
@Component
@Scope("prototype")
public @interface ScheduledJob {..}
因此,所有用@ScheduledJob注释的类都是springbean,除此之外,它们还注册为石英作业。您只需要提供处理特定注释的代码。
其他回答
A@Service引用spring文档,
指示带注释的类是最初定义的“服务”被领域驱动设计(Evans,2003)称为“接口在模型中独立,没有封装状态。"也可以表示类是“业务服务外观”(在核心J2EE模式感觉)或类似的东西。此注释是通用刻板印象和单个团队可能会缩小语义并酌情使用。
如果你看看eric evans的领域驱动设计,
SERVICE是作为独立于模型,没有封装状态,作为ENTITIES和VALUE OBJECTS服务是技术框架中的一种常见模式,但它们也可以应用于域层。名称服务强调与其他对象的关系。与实体和价值对象不同纯粹是根据它可以为客户做什么来定义的。服务倾向于以活动而非实体命名,而不是动词而不是名词。SERVICE仍然可以具有抽象的、故意的释义它只是有一种不同于对象服务仍应具有明确的责任责任和履行责任的接口应定义为域模型的一部分。操作名称应来自通用语言或被引入其中。参数和结果应该是域对象。应明智地使用服务,而不是允许删除实体和值对象的所有行为。但当一个操作实际上是一个重要的领域概念时服务是模式驱动设计的自然组成部分。声明于将模型作为一种服务,而不是作为一个假的对象实际上,独立操作不会误导任何人任何人
以及根据Eric Evans,
REPOSTORY将特定类型的所有对象表示为概念对象设置(通常是模拟的)。它就像一个集合,除了有更多详细的查询功能。适当类型的对象包括添加和删除,以及REPOSTORY插件后面的机械或从数据库中删除它们。此定义收集了提供访问根从生命周期早期到生命周期结束的聚集。
@Component、@Repository、@Controller和@Service注释之间的差异
@组件–通用,可跨应用程序使用@服务–在服务层级别注释类@控制器–注释表示层级别的类,主要用于SpringMVC。@Repository–在持久层注释类,它将充当数据库存储库。
@控制器=@Component(内部注释)+表示层功能@服务=@Component(内部注释)+服务层功能@分量=实际分量(豆类)@Repository=@Component(内部注释)+数据层特性(用于处理域bean)
我们可以根据java标准回答这个问题
参考JSR-330,它现在被spring支持,您只能使用@Named来定义bean(不知何故,@Named=@Component)。因此,根据这个标准,似乎没有必要为类别bean定义原型(如@Repository、@Service、@Controller)。
但是spring用户在这些不同的注释中有不同的特定用途,例如:
帮助开发人员为胜任者定义更好的类别。这种分类在某些情况下可能会有所帮助。(例如,当您使用面向方面的时,这些可能是切入点的好候选)@存储库注释将为bean添加一些功能(为bean持久层添加一些自动异常转换)。如果您使用的是springMVC,则@RequestMapping只能添加到由@Controller注释的类中。
Spring支持多种类型的注释,如@Component、@service、@Repository。所有这些都可以在org.springframework.stereotype包下找到,@Bean可以在org.spring framework.context.annotation包下找到。
当我们的应用程序中的类使用上述任何注释进行注释时,在项目启动期间,对每个类进行春季扫描(使用@ComponentScan),并将类的实例注入IOC容器。@ComponentScan要做的另一件事是运行带有@Bean的方法,并将返回对象作为Bean还原到Ioc容器。
在深入研究(@Component vs@service vs@Repository)之前,最好先了解@Bean和@Component之间的区别
@组件vs@存储库vs@服务
在大多数典型的应用程序中,我们有不同的层,如数据访问、表示、服务、业务等。此外,在每个层中,我们都有不同的bean。为了自动检测这些bean,Spring使用类路径扫描注释。然后在ApplicationContext中注册每个bean。
以下是其中一些注释的简短概述:
@组件是任何Spring管理组件的通用原型。@服务在服务层注释类。@Repository在持久层对类进行注释,持久层将充当数据库存储库。
@零部件注释
@Component是一个类级别的注释。我们可以在应用程序中使用@Component将bean标记为Spring的托管组件。Spring只会使用@Component获取和注册bean,通常不会查找@Service和@Repository。
它们在ApplicationContext中注册,因为它们用@Component注释
如前所述,@Component是所有原型注释的父级。当Spring执行组件扫描时,它只查找标记有@component注释的类。
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Indexed
public @interface Component {
String value() default "";
}
我们可以在所有类上使用这个注释,它不会造成任何差异。
@服务注释
我们用@Service标记bean,以表示它们持有业务逻辑。除了在服务层中使用之外,该注释没有任何其他特殊用途。
@Service是组件的子级,用于表示应用程序服务层的类。
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Service {
@AliasFor(
annotation = Component.class
)
String value() default "";
}
@存储库批注
@Repository的任务是捕获特定于持久性的异常,并将其作为Spring的统一未检查异常之一重新抛出。
为此,Spring提供了PersistenceExceptionTranslationPostProcessor,我们需要将其添加到应用程序上下文中(如果我们使用的是Spring Boot,则已经包括在内):
<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>
这个bean后处理器向用@Repository注释的任何bean添加一个advisor。
类似地,@Repository也是组件注释的子级,用于属于持久性数据访问层并用作数据存储库的类。
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Repository {
@AliasFor(
annotation = Component.class
)
String value() default "";
}
总结
@Service和@Repository是@Component的特例。它们在技术上是相同的,但我们使用它们的目的不同。根据它们的层约定选择注释总是一个好主意。
存储库和服务是组件注释的子级。所以,它们都是组件。存储库和服务只是扩展它。具体如何?服务只有意识形态上的区别:我们把它用于服务。存储库具有特定的异常处理程序。