使用applicationcontext.getbean与@configurable的优势

Question

与没有由bean di applicationcontext.getbean？管理的bean相比，使用@可配置的优点是什么？有谁列出赞成和反对的吗？

Answer 1

我要拿-20来做这个。即使是臭名昭著的马丁·福勒( Martin Fowler )发明了“依赖注入”这个可怕的名字，也不认为它更适合于测试：

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

--人们偏爱依赖注入的一个常见原因是，它使测试变得更容易。这里的要点是，要进行测试，您需要轻松地用存根或模拟替换真正的服务实现。但是，在这里，依赖注入和服务定位器实际上并没有什么区别:两者都非常容易死掉。我怀疑这种观察来自于一些项目，在这些项目中，人们没有努力确保他们的服务定位器可以很容易地被替换。这就是持续测试的帮助所在，如果您不能轻松地将服务存根用于测试，那么这就意味着您的设计出现了严重的问题。

以下是我的反对意见：

1. DI将实现依赖项转化为接口依赖项。你的课被那些不该去的赛特人污染了。是的，真正的结帐过程取决于信用卡服务、邮件服务、数据库服务以及谁知道明天会发生什么，但我们不应该宣传这些依赖关系。他们是临时的，按需的，没有界面价值。也许下个月整个结帐过程会减少到一个REST call.
2. Performance.。服务通常不需要在一种方法之外。DI要求每个服务至少需要一个字段变量，并且只要主机对象是活动的，就会引用它。如果服务有每个客户端的状态，这是非常糟糕的。我不是一个对性能敏感的人，但这感觉是不对的。用于生产环境的
3. 编码变得更加困难。想想你添加了多少锅炉板代码来使用DI，每次你需要一个服务。都是为了让测试更容易。首先-什么？！生产是第一要务；测试应该对它和它起作用，而不是相反。测试不是宗教，伙计们！专注于生产环境，担心以后的测试。第二，测试现在真的更容易吗?在测试中，
4. 只需模拟几个服务就可以了，这些服务很重，涉及到VM之外的活动。有了服务定位器，您就有了包含这些模拟服务的测试配置，就完成了。您的签出过程可以在没有任何麻烦的情况下进行测试，以及所有依赖于这些服务的类。在DI中，您必须在每个单元测试中手动管理这些依赖项。-But！但是有了DI，您现在就可以为不同的测试单元提供不同的模拟邮件服务了！哦，太好了！
5. “DI鼓励统一的服务配置方式”--只有在使用相同的框架的情况下。实际上，它与DI无关；框架执行一种配置方式，您也可以认为Spring鼓励采用统一的服务定位方法。当一个框架被广泛使用时，它可以成为一个事实上的标准，因此可以使不同的开发人员更容易交谈--只是因为网络效应，而不是其设计选择中的任何固有优点。

总之，它不利于设计，不利于性能，不利于生产，不利于测试，不利于标准的制定。它有什么好处？这就像许多在很久以前就有可疑来源的愚蠢的规则和惯例，但我们仍然每天都盲目地遵循它们。这就是社会运转的原因。

编辑:转发到有关DI和测试Does using annotations to inject dependencies remove the main benefit of dependency injection(external configuration)?的新问题的链接

Answer 2

执行applicationContext.getBean()完全违背了依赖注入的目的，因为不再是注入依赖项。应用程序上下文XML文件很好。基于注释的配置(自动配线)也很好。这样你也可以这样做：

Service service = new Service();

或者更糟：

Service service = ServiceLocator.locate("service");

这两种情况都会使您的代码难以测试。