存储库和服务是组件注释的子级。所以，它们都是组件。存储库和服务只是扩展它。具体如何？服务只有意识形态上的区别：我们把它用于服务。存储库具有特定的异常处理程序。

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

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

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

它们几乎相同——所有这些都意味着这个类是一个Spring bean@Service、@Repository和@Controller是专门的@Components。您可以选择与他们一起执行特定操作。例如：

@springmvc使用控制器bean@存储库bean有资格进行持久性异常转换

另一件事是将组件语义上指定给不同的层。

@Component提供的一点是，您可以用它注释其他注释，然后以与@Service相同的方式使用它们。

例如，最近我做了：

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

因此，所有用@ScheduledJob注释的类都是springbean，除此之外，它们还注册为石英作业。您只需要提供处理特定注释的代码。

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

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

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

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

A@Service引用spring文档，

指示带注释的类是最初定义的“服务”被领域驱动设计（Evans，2003）称为“接口在模型中独立，没有封装状态。"也可以表示类是“业务服务外观”（在核心J2EE模式感觉）或类似的东西。此注释是通用刻板印象和单个团队可能会缩小语义并酌情使用。

如果你看看eric evans的领域驱动设计，

SERVICE是作为独立于模型，没有封装状态，作为ENTITIES和VALUE OBJECTS服务是技术框架中的一种常见模式，但它们也可以应用于域层。名称服务强调与其他对象的关系。与实体和价值对象不同纯粹是根据它可以为客户做什么来定义的。服务倾向于以活动而非实体命名，而不是动词而不是名词。SERVICE仍然可以具有抽象的、故意的释义它只是有一种不同于对象服务仍应具有明确的责任责任和履行责任的接口应定义为域模型的一部分。操作名称应来自通用语言或被引入其中。参数和结果应该是域对象。应明智地使用服务，而不是允许删除实体和值对象的所有行为。但当一个操作实际上是一个重要的领域概念时服务是模式驱动设计的自然组成部分。声明于将模型作为一种服务，而不是作为一个假的对象实际上，独立操作不会误导任何人任何人

以及根据Eric Evans，

REPOSTORY将特定类型的所有对象表示为概念对象设置（通常是模拟的）。它就像一个集合，除了有更多详细的查询功能。适当类型的对象包括添加和删除，以及REPOSTORY插件后面的机械或从数据库中删除它们。此定义收集了提供访问根从生命周期早期到生命周期结束的聚集。

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将自动创建那些在上下文创建/加载阶段用上面的注释注释的类的对象。