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

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

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


当前回答

@Component、@Service、@Controller、@Repository之间没有区别。@Component是表示MVC组件的泛型注释。但作为MVC应用程序的一部分,将有几个组件,如服务层组件、持久层组件和表示层组件。所以为了区分它们,Spring的人也给出了其他三个注释。

表示持久层组件:@Repository表示服务层组件:@service表示表示层组件:@Controller否则,您可以对所有组件使用@Component。

其他回答

Spring2.5引入了更多的原型注释:@Component、@Service和@Controller@组件充当任何Spring管理组件的通用原型;而@Repository、@Service和@Controller作为@Component的特殊化,用于更具体的用例(例如,分别在持久性、服务和表示层)。这意味着你可以用@component来注释你的组件类,但是通过用@Repository、@Service或@Controller来注释它们,你的类更适合由工具处理或与方面关联。例如,这些原型注释是切入点的理想目标。当然,@Repository、@Service和@Controller也有可能在未来的Spring Framework版本中携带额外的语义。因此,如果您在服务层使用@Component或@Service之间做出决定,@Service显然是更好的选择。类似地,如上所述,@Repository已经被支持作为持久层中自动异常转换的标记。@组件–表示自动扫描组件。@Repository–表示持久层中的DAO组件。@服务–表示业务层中的服务组件。@控制器–表示表示层中的控制器组件。

参考:-Spring Documentation-Classpath扫描、托管组件和使用Java编写配置

In-spring框架提供了一些特殊类型的注释,称为原型注释。具体如下:-

@RestController- Declare at controller level.
@Controller – Declare at controller level.
@Component – Declare at Bean/entity level.
@Repository – Declare at DAO level.
@Service – Declare at BO level.

上面声明的注释是特殊的,因为当我们将<context:componentscan>添加到xxx-servlet.xml文件中时,spring将自动创建那些在上下文创建/加载阶段用上面的注释注释的类的对象。

从数据库连接的角度来看,使用@Service和@Repository注释很重要。

对所有web服务类型的DB连接使用@Service将@Repository用于所有存储过程数据库连接

如果没有使用正确的注释,则可能会遇到回滚事务覆盖的提交异常。您将在压力负载测试期间看到与回滚JDBC事务相关的异常。

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

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

从Spring源代码:

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

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

每个注释的目的:

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

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

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

即使它的行为相同,但这利用了应用程序的许多软件开发原则,也很少有这样的例子:

- Single Responsibility
- Open Closed Principal