自动装配的CDI比Spring更差？

面对现实吧，有两种开发人员：支持Spring自动装配的开发人员，因为它减轻了他们编写XML的负担（即使您可以使用XML进行自动装配），以及那些将自动装配视为危险的开发人员。

我必须承认我属于第二品牌。 实际上，我宁愿面对800磅重的大猩猩，也不愿使用自动装配。 当然，这为您完成了所有工作，不是吗？ 也许吧，但这是一项艰苦的工作，我宁愿弄脏我的手，也不愿让一些廉价的机器人替我做这件事。 问题的根源在于自动装配的隐含性 。 您声明两个bean，说一个需要另一个，然后我们离开。

在纸上看起来很简单，那就是我们是否允许这样做。 现在，自动装配有两种主要方式：

• 通过名称在属性名称和Bean名称之间进行匹配
• 按类型，其中在属性的类型和bean的类型之间进行匹配

前者虽然相对良性，但可能导致命名梦night，开发人员将调整名称以使其自动装配在一起。 第二个完全是胡说八道：在这种情况下，您可以在工作上下文中通过在其中创建一个bean来产生问题，这仅仅是因为它具有与上下文中已经存在的另一个bean相同的类。 更糟糕的是，自动布线错误可能会在一个完全不相关的位置发生，这仅仅是因为自动布线涉及的魔力。 不，解决方案不是混合使用自动装配和显式装配，在名称和类型之间混合使用自动装配，甚至不将bean排除在自动装配的候选对象之外。 由于开发人员不得不不断地质疑行为是什么，这只会加剧复杂性。

不确信的自动布线风扇应阅读Spring文档本身，以获取限制和缺点的列表。 这并不是说自动布线本身是不好的，只是必须严格控制。 到目前为止，我只允许小型团队和测试使用（ 即，代码不会交付生产）。

总而言之，Spring自动装配具有一种赎回质量：仅从上下文中选择候选对象，这意味着上下文之外的实例不会破坏我们精心设计的应用程序。

CDI开发人员应该暗示我要去的地方。 由于在CDI中，类路径上的每个类都是自动装配的候选对象，因此这意味着在应用程序的类路径上添加新的JAR可能会破坏CDI并阻止应用程序启动。 因此，对于CDI，仅应使用名称自动布线...然后，只有勇于冒险的人才能使用DI

翻译自: https://blog.frankel.ch/cdi-worse-than-spring-for-autowiring/