Stackoverflow的见解：投票最多的是Spring 4问题

在Stackoverflow上对Spring 4问题进行最投票和回答最多的是什么？以下是最常见的五个问题和解答。

Spring中的@ Component，@ Controller，@ Repository和@Service批注有什么区别，它们可以互换使用还是具有特定功能？
@Transaction注释在哪里？ DAO类，调用DAO的服务还是两者？
@Inject和@Autowired有什么区别？在什么条件下使用哪一个？
我应该使用@Resource或@Autowired哪个注释？有什么区别？
Spring Framework的用途是什么？

Spring中的@ Component，@ Controller，@ Repository和@Service批注有什么区别，它们可以互换使用还是具有特定功能？

这些构造型旨在标记多层应用程序中的不同层。业务，表示层和持久层中的组件分别由@ Service ， @ Component和@Repository进行注释，如下所示：

数据访问组件带有@Repository批注
服务组件@Service
控制器组件带有@Controller批注
其他任何组件都用@Component注释。

所有这些注释本身都使用@Component进行注释。所以问题是：我们可以对所有自动扫描的类使用@Component吗？是的，没有！

所有带有此批注标记的类都将被自动扫描，但是，由于这些批注旨在帮助开发人员清楚地传达组件的意图，因此不会被视为一种好的做法。

这些注释的技术互换性有一个例外。 @Repository标记为其注释的所有bean赋予特殊行为。 PersistenceExceptionTranslationPostProcessor自动将持久性异常转换应用于标记有@Repository的任何bean。

考虑一下Spring框架参考手册中的以下段落。

后处理器自动查找所有异常转换器（PersistenceExceptionTranslator接口的实现），并建议所有标有@Repository批注的bean，以便发现的转换器可以拦截适当的转换并将其应用于引发的异常。

进一步的考虑是，在Spring框架的未来版本中，使用这些批注可能会传达与其各自层有关的特殊功能，并且通过适当地使用这些批注，您可以确保您的应用程序将受益于此类功能，而无需进行重构或进行最少的重构。

原始问题和答案可以在Stackoverflow网站上查看。感谢以下回答它们构成本文一部分的海报： akash746 ， nijogeorgep和Colin McCree提出了原始问题。

DAO类，调用DAO的服务还是两者？

答案分为两个阵营：那些赞成在服务层上注释类的人，以及那些对DAO进行注释的人。

服务层

传统的Spring体系结构建议事务性语义位于服务级别。操作的原子性应为我们的决定提供依据。事务注释应放在所有不可分割的操作周围。考虑汇款的经典示例。它包含以下调用：

记入发送帐户
扣款收款人帐户

这两个事务都必须成功或失败，因此事务必须同时包含调用1和2。

如果服务层必须在数据访问层中的DAO上调用不同的方法以执行完整的操作，并且其中一个调用失败，而其他成功则可能导致数据库状态不一致。因此，在服务层进行的调用周围注释将保护操作的原子性。

为了进一步确定，您可能希望通过添加@Transactional（propagation = Propagation.MANDATORY）在数据访问层中注释借方和贷方通话。这将确保事务已在调用方中启动，并且如果不存在活动事务，则将引发异常。

与在DAO方法上进行直接注释相比，对服务层进行注释可能会导致更持久的事务。您做出的选择将取决于业务逻辑所需的级别事务隔离。

道

领域驱动设计正在出现一种新兴趋势。 Spring Roo是这种趋势的一个很好的例子。

这样做的目的是使域对象比传统的Spring架构丰富得多，通常它们是贫血的，尤其是将事务和持久性语义放在域对象本身上。

在仅需简单的CRUD操作的用例中，Web控制器将直接在域对象上运行（在此上下文中充当实体），并且没有服务层。

如果域对象之间需要某种形式的协调，则可以按照传统使用@Transaction来具有服务bean句柄。您可以将域对象上的事务传播设置为REQUIRED之类，以便域对象使用任何现有事务，例如在服务bean处启动的事务。

原始问题和答案可以在Stackoverflow网站上查看。感谢以下回答这些问题的张贴者，这些张贴者构成了本文的一部分： Willie Wheeler ， Michael Wiles ， mnp ， tweekran ， djt和Thomas Einwaller提出了原始问题。

在什么条件下使用哪一个？

简短的答案：没有区别，可以互换使用。

更详细地，@ Inject注释是Java EE 7的上下文和依赖性注入框架的一部分（ JSR 346另请参见JSR 365 for Java 2.0），而@Autowired是Spring框架自己的实现（请参阅Java doc ）。

原始问题和答案可以在Stackoverflow网站上查看。感谢以下回答它们构成本文一部分的海报： pap和Rachel提出了原始问题。

有什么区别？

@Autowired （或@Inject ）和@Resource批注具有相同的功能。但是有一个概念上的区别：

@Resource应该用于通过名称获取已知资源。名称是从带注释的设置器或字段中提取的，或者是从注释的名称参数的名称中获取的。
@Inject或@Autowired批注尝试按类型注入合适的组件。

本质上，这是两个不同的概念。令人失望的是，Spring的@Resource批注实现具有内置的回退，当解析按名称失败时会触发该回退。它回退到@Autowired批注所使用的分辨率类型。尽管这种回退很方便，但是由于人们没有意识到概念上的差异，因此可能会造成混乱，并且倾向于使用@Resource进行基于类型的注入。

选择依赖项的方式特定于注释。以下是每个批注解决注入的方式：

@Autowired和@Inject

按类型匹配
受预选赛限制
按名称匹配

@资源

按名称匹配
按类型匹配
受限定词限制（如果按名称找到匹配项则忽略）

Spring参考手册中的这句话建议使用@Resource而不是@Autowired ，其中首选使用名称注入。

如果您打算通过名称表示注释驱动的注入，则即使技术上可以通过@Qualifier值引用bean名称，也不要主要使用@Autowired 。 而是使用JSR-250 @Resource批注，该批注的语义定义是通过其唯一名称标识特定的目标组件，而声明的类型与匹配过程无关。

由于这种语义差异的特定结果，本身定义为集合或映射类型的bean无法通过@Autowired注入，因为类型匹配不适用于它们。 对此类bean使用@Resource ，通过唯一名称引用特定的collection或map bean。

@Autowired适用于字段，构造函数和多参数方法，从而允许在参数级别缩小限定符注释的范围。 相比之下，只有具有单个参数的字段和bean属性设置器方法才支持@Resource 。 因此，如果注入目标是构造函数或多参数方法，请坚持使用限定符。