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

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

1. Spring中的@ Component，@ Controller，@ Repository和@Service批注有什么区别，它们可以互换使用还是具有特定功能？
2. @Transaction注释在哪里？ DAO类，调用DAO的服务还是两者？
3. @Inject和@Autowired有什么区别？ 在什么条件下使用哪一个？
4. 我应该使用@Resource或@Autowired哪个注释？ 有什么区别？
5. 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. 扣款收款人帐户

这两个事务都必须成功或失败，因此事务必须同时包含调用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

1. 按类型匹配
2. 受预选赛限制
3. 按名称匹配

@资源

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

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

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

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

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

原始问题和答案可以在Stackoverflow网站上查看。 谢谢以下海报谁的答案这篇文章的组成部分： 卡尔蒂克 ， 斯蒂芬 ， Ichthyo和mlo55谁问原来的问题。

Spring Framework的用途是什么？

Spring Framework可以描述为三种方式：

1. Spring是用于依赖项注入的框架：一种设计模式，允许开发人员通过将依赖项注入到类中来构建非常分离的系统。
2. 它优雅地包装了Java库，从而使它在您的应用程序中更容易使用。
3. 该框架中包括常用模式的实现，例如REST和MVC Web框架，这些模式主要在Web应用程序中使用。

原始问题和答案可以在Stackoverflow网站上查看。 感谢以下回答这些问题的海报，它们是本文的一部分： karstensrage和maksim ，他们提出了原始问题。

我希望您发现对stackoverflow上最受欢迎的问题的理解很有意思。 如果您有任何反馈意见，请发表评论。 可以在这里找到本文的原始文章： Stackoverflow的见解：Spring 4投票最多的问题。

如果您对设计模式感兴趣，那么您可能会对我的新书感兴趣： Professional Java EE Design Patterns 。 对于想要更有效地使用Java EE的任何人来说，它都是一个完美的伴侣，并且是涵盖解决实际问题的设计模式的理论和应用的唯一资源。

翻译自: https://www.javacodegeeks.com/2016/02/insights-stackoverflow-voted-spring-4-questions.html