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

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

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


当前回答

来自Spring文档:

@Repository注释是满足存储库的角色或原型(也称为数据访问对象或DAO)。该标记的用途之一是自动翻译异常,如异常转换中所述。Spring提供了更多的原型注释:@Component、@Service、,和@Controller@组件是任何Spring管理的组件@Repository、@Service和@Controller是@Component的专门化,用于更具体的用例(在持久性、服务和表示层)。因此,您可以使用@component注释组件类,但是,通过用@Repository、@Service或@Controller注释它们相反,您的类更适合由工具处理或与方面相关。例如,这些原型注释成为切入点的理想目标@存储库、@Service和@控制器还可以在未来版本的Spring框架。因此,如果您在使用@组件或服务层的@Service,@Service显然是更好的选择。同样,如前所述,@Repository已经支持作为自动异常转换的标记持久层。

Annotation Meaning
@Component generic stereotype for any Spring-managed component
@Repository stereotype for persistence layer
@Service stereotype for service layer
@Controller stereotype for presentation layer (spring-mvc)

其他回答

由于许多答案已经说明了这些注释的用途,我们将在这里重点讨论它们之间的一些细微差异。

首先是相似性值得再次强调的第一点是,关于扫描自动检测和BeanDefinition的依赖注入,@Repository、@Controller)是相同的。我们可以就地使用另一个的,仍然可以得到我们的方式。


@Component、@Repository、@Controller和@Service之间的差异

@组件

这是一个通用的原型注释,表明该类是一个弹簧组件。

@Component有什么特别之处<context:componentscan>仅扫描@component,通常不查找@Controller、@Service和@Repository。它们被扫描,因为它们本身带有@Component注释。

只需查看@Controller、@Service和@Repository注释定义即可:

@Component
public @interface Service {
    ….
}

 

@Component
public @interface Repository {
    ….
}

 

@Component
public @interface Controller {
    …
}

因此,@Controller、@Service和@Repository是@Component注释的特殊类型并不是错误的<context:componentscan>拾取它们并将它们的以下类注册为bean,就像它们用@component注释一样。

特殊类型注释也会被扫描,因为它们本身是用@Component注释注释的,这意味着它们也是@Components。如果我们定义自己的自定义注释并使用@Component对其进行注释,那么它也将通过<context:componentscan>进行扫描


@存储库

这表示该类定义了一个数据存储库。

@Repository有什么特别之处?

除了指出这是一个基于注释的配置之外,@Repository的工作是捕获特定于平台的异常,并将其作为Spring的统一未检查异常之一重新抛出。为此,我们提供了PersistenceExceptionTranslationPostProcessor,需要将其添加到Spring的应用程序上下文中,如下所示:

<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/>

这个bean后处理器向用@Repository注释的任何bean添加一个advisor,以便捕获任何特定于平台的异常,然后作为Spring未检查的数据访问异常之一重新抛出。


@控制器

@Controller注释表示特定类充当控制器的角色。@Controller注释充当注释类的原型,指示其角色。

@Controller有什么特别之处?

我们无法将此注释与任何其他注释(如@Service或@Repository)切换,即使它们看起来相同。分派器扫描用@Controller注释的类,并检测其中用@RequestMapping注释注释的方法。我们只能在类用@Controller注释的方法上/中使用@RequestMapping,它不能与@Component、@Service、@Repository等一起使用。。。

注意:如果一个类已经通过任何替代方法注册为bean,例如通过@bean或通过@Component、@Service等注释,那么如果该类也使用@RequestMapping注释进行注释,则可以选择@RequestMapping。但情况不同。


@服务

@服务bean在存储库层中保存业务逻辑和调用方法。

@Service有什么特别之处?

除了它用来表示,它持有业务逻辑之外,这个注释中没有其他值得注意的地方;但谁知道呢,Spring可能会在未来增加一些额外的例外。


还有什么?

与上述类似,未来Spring可能会根据其分层约定为@Service、@Controller和@Repository添加特殊功能。因此,尊重惯例并按照层使用它总是一个好主意。

@组件在配置类中充当@Bean注释,在spring上下文中注册Bean。它也是@Service、@Repository和@Controller注释的父级。

@服务,扩展了@Component注释,只有命名差异。

@Repository-扩展@Component注释并将所有数据库异常转换为DataAccessException。

@控制器-在MVC模式中充当控制器。分派器将扫描这些带注释的类以查找映射方法,检测@RequestMapping注释。

@组件等效于

<bean>

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

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

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

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

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

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

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

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

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

@Component
@Controller
@Repository
@Service
@RestController

这些都是StereoType注释。这对于在ioc容器中将我们的类制作为springbean非常有用,

@组件、@Repository、@Service、@Controller:

@Component是由Spring@Repository、@Service和@Controller管理的组件的通用原型,是用于更具体用途的@Component专用化:

@持久性存储库@服务和交易服务@MVC控制器的控制器

为什么在@Component上使用@Repository、@Service、@Controller?我们可以用@component标记我们的组件类,但如果相反,我们使用适应预期功能的替代方法。我们的类更适合每种特定情况下的预期功能。

用@Repository注释的类使用org.springframework.dao.DataAccessException具有更好的翻译和可读错误处理。非常适合实现访问数据的组件(DataAccessObject或dao)。

带有@Controller的注释类在SpringWebMVC应用程序中扮演控制器角色

带有@Service的注释类在业务逻辑服务中发挥作用,例如DAO Manager(Facade)的Facade模式和事务处理