@Component、@Repository和@Service注释是否可以在Spring中互换使用,或者它们除了充当符号设备之外,是否提供任何特定功能?

换句话说,如果我有一个Service类,并且我将注释从@Service更改为@Component,它的行为是否仍然相同?

或者注释是否也会影响类的行为和功能?


当前回答

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的特例。它们在技术上是相同的,但我们使用它们的目的不同。根据它们的层约定选择注释总是一个好主意。

其他回答

这里给出的答案在技术上是部分正确的,但即使答案列表很长,这将是底部,我认为在这里也应该给出一个真正正确的答案,以防有人偶然发现并从中学习到有价值的东西。这并不是说其余的答案完全错误,只是它们不正确。而且,为了阻止成群的巨魔,是的,我知道,从技术上讲,这些注释现在实际上是一样的,甚至到第5春,它们都可以互换。现在,对于正确的答案:

这三种注释是完全不同的,不可互换。你可以这么说,因为他们有三个而不是一个。它们并不是可互换的,它们只是出于优雅和方便而实现的。

现代编程是不同比例的发明、艺术、技术和通信。通信位通常非常重要,因为代码的读取频率通常比编写频率高得多。作为一名程序员,你不仅试图解决技术问题,还试图将你的意图传达给阅读你代码的未来程序员。这些程序员可能既不共享您的母语,也不共享您所处的社交环境,而且他们可能在未来50年内阅读您的代码(这并不像您想象的那样不可能)。在未来很难有效地沟通。因此,我们必须使用最清晰、最有效、最正确、最具交际能力的语言。我们谨慎地选择词汇,以产生最大的影响,并尽可能清楚地表达我们的意图。

例如,在编写存储库时使用@Repository而不是@Component是非常重要的。后者对于存储库来说是一个非常糟糕的注释选择,因为它并不表示我们正在查看存储库。我们可以假设存储库也是一个springbean,但不能假设组件是一个存储库。有了@Repository,我们的语言变得清晰而具体。我们明确表示,这是一个存储库。有了@Component,我们就让读者来决定他们阅读的是什么类型的组件,他们必须阅读整个类(以及可能的子类和接口树)来推断含义。在遥远的将来,该类可能会被读者误解为不是一个存储库,我们可能会对这个错误承担部分责任,因为我们深知这是一个存储,但未能在我们的语言中明确表达我们的意图。

我将不讨论其他示例,但将尽可能清楚地说明:这些注释是完全不同的东西,应根据其意图适当使用@存储库用于存储存储库,其他注释都不正确@服务用于服务,其他注释不正确@控制器适用于既不是存储库也不是服务的组件,在其位置使用其中任何一个都是不正确的。它可能会编译,甚至可能运行并通过您的测试,但这是错误的,如果您这样做的话,我会对您(专业)的评价降低。

整个春季都有这样的例子(以及一般的编程)。编写REST API时不能使用@Controller,因为@RestController可用。当@GetMapping是有效的替代方案时,不能使用@RequestMapping。你必须选择最具体、最准确、最正确的语言来向读者传达你的意图,否则,你会给你的系统带来风险,风险是有代价的。

最后,我想提出一个关于面向对象系统的问题。基本规则之一是,实现可以变化,但接口不应该变化。假设这些注释是相同的,这是一个非常棘手的问题,完全违背OO。尽管它们现在可能以可互换的方式实现,但不能保证将来会实现。此外,即使在同一个团队中,工程师也可能会决定使用方面暂停这些注释中的一个或多个,或者平台工程师可能会出于操作原因选择替换其中一个的实现。你只是不知道,也不应该知道——在OO中,你依赖的是接口,而不是实现。

即使我们交换@Component或@Repository或@service

它的行为是一样的,但一个方面是,如果我们使用component或@service,它们将无法捕获与DAO相关的特定异常,而不是Repository

@组件等效于

<bean>

@服务,@Controller,@Repository={@Component+一些更特殊的功能}

这意味着服务、控制器和存储库在功能上是相同的。

这三个注释用于分离应用程序中的“层”,

控制器只是做一些事情,比如调度、转发、调用服务方法等。服务保留业务逻辑、计算等。存储库是DAO(数据访问对象),它们直接访问数据库。

现在您可能会问为什么要将它们分开:(我假设您知道AOP面向方面编程)

假设您只想监视DAO层的活动。您将编写一个Aspect(A类)类,该类在调用DAO的每个方法之前和之后进行一些日志记录,您可以使用AOP来实现这一点,因为您有三个不同的层,并且没有混合。

因此,您可以在DAO方法的“周围”、“之前”或“之后”记录DAO。你可以这样做,因为你一开始就有一个DAO。您刚刚实现的是关注点或任务的分离。

想象一下,如果只有一个注解@Controller,那么这个组件的调度、业务逻辑和访问数据库都会混合在一起,代码太脏了!

上面提到的是一个非常常见的场景,还有很多使用三个注释的用例。

@Component:你注释一个类@Component,它告诉hibernate它是一个Bean。

@Repository:您注释一个类@Repositories,它会告诉hibernate它是一个DAO类,并将其视为DAO类。意味着它使未检查的异常(从DAO方法抛出)有资格转换为SpringDataAccessException。

@服务:这告诉hibernate它是一个服务类,您将在其中使用@Transactional等服务层注释,因此hibernate将其视为服务组件。

另外,@Service是@Component的进步。假设bean类名为CustomerService,因为您没有选择XMLbean配置方式,所以您使用@Component注释了bean,以将其指示为bean。因此,在获取bean对象CustomerService cust=(CustomerService)context.getBean(“CustomerService”)时;默认情况下,Spring会将组件的第一个字符从“CustomerService”小写为“CustomerService”。您可以检索名为“customerService”的组件。但是,如果对bean类使用@Service注释,则可以通过以下方式提供特定的bean名称

@Service("AAA")
public class CustomerService{

您可以通过

CustomerService cust = (CustomerService)context.getBean("AAA");

这些是Stereotype注释,可用于自动扫描

从技术上讲,@Controller、@Service、@Repository都是相同的。它们都扩展了@Component。

从Spring源代码:

指示带注释的类是“组件”。当使用基于注释的配置和类路径扫描时,此类类被视为自动检测的候选类。

我们可以对每个bean直接使用@Component,但为了更好地理解和维护大型应用程序,我们使用@Controller、@Service、@Repository。

每个注释的目的:

@带有此注释的Controller->类旨在接收来自客户端的请求。第一个请求来自DispatcherServlet,它使用@RequestMapping注释的值将请求传递给特定的控制器。@带有此注释的服务->类旨在处理我们从客户端接收或从数据库获取的数据。所有的数据操作都应该在这个层中完成。@存储库->带有此注释的类用于连接数据库。它也可以被认为是DAO(数据访问对象)层。该层应仅限于CRUD(创建、检索、更新、删除)操作。如果需要任何操作,数据应发送回@Service层。

如果我们交换它们的位置(使用@Repository代替@Controller),我们的应用程序将正常工作。

使用三种不同的@注释的主要目的是为Enterprise应用程序提供更好的模块性。