使用applicationcontext.getbean与@configurable相比的优势

Question

与 不是由bean* 通过 applicationcontext.getbean 进行管理的bean 相比，使用
@configurable有 什么优势？任何人列出的利弊？
***

Answer 1

我要为此得到 -20 。即使是臭名昭著的马丁·福勒（Martin Fowler）发明了这个可怕的“依赖注入”名称，也认为它不适合测试：

http://martinfowler.com/articles/injection.html

人们偏爱依赖注入的一个普遍原因是它使测试更加容易。这里的重点是进行测试，您需要轻松地用存根或模拟替换真实的服务实现。但是，依赖注入和服务定位器之间实际上并没有什么区别：两者都非常适合存根。我怀疑这种观察来自于人们没有努力确保可以轻松替换其服务定位器的项目。这是持续测试的地方，如果您不能轻易地对服务进行存根测试，那么这意味着您的设计存在严重问题。

这是我的反对意见：

1. DI将实现依赖关系转换为接口依赖关系。您的班级受到二传手的污染，否则他们不应该去那里。是的，真正的结帐流程取决于信用卡服务，邮件服务，数据库服务以及谁知道什么明天，但我们不应该宣传这些依赖项。它们是临时的，按需的，而不是界面友好的。也许下个月，整个结帐过程将简化为REST调用。

2. 性能。一种方法通常不需要服务。DI对于每个服务至少需要一个字段变量，并且只要宿主对象是活动的，就必须对其进行引用。如果服务具有每个客户端状态，这是非常糟糕的。我不是一个对性能敏感的人，但这感觉是错误的。

3. 生产环境的编码变得更加困难。想想一下，每次需要服务时，添加了多少样板代码以使用DI。一切都是为了简化测试。首先-什么？生产是第一要务；测试应该适用于它，并且与此相反，而不是相反。 测试不是一种宗教，人们！ 专注于生产环境，以后再担心测试。第二-现在测试真的容易吗？

4. 在测试中，您只需要模拟一些繁重且涉及VM外活动的服务。使用服务定位器，您将获得一个包含这些模拟服务的测试配置，然后就可以完成。您的结帐流程以及依赖于这些服务的所有类都可以轻松进行测试。在DI中，您必须在 每个 单元测试中手动管理那些依赖项。-但！但是，有了DI，您现在就可以灵活地为不同的测试单元提供不同的模拟邮件服务！哦，对你有好处！

5. “ DI鼓励采用统一的服务配置方式”- 仅当 您使用相同的框架时。实际上，它与DI无关；框架强制执行一种配置方式，您也可以说Spring鼓励采用统一的服务定位方式。当一个框架被广泛使用时，它可以成为事实上的标准，因此使不同的开发人员之间的交流变得更加容易-仅仅是因为网络的影响，而不是因为其设计选择固有的优势。

总之，这不利于设计，不利于性能，不利于生产，不利于测试并且与设置标准无关。到底有什么好处呢？就像很早以前就建立了许多可疑起源的愚蠢规则和惯例一样，但我们仍然每天都盲目地遵循它们。这就是使社会运转的原因。