使用applicationcontext.getbean vs @configurable的优势 [英] advantage of using applicationcontext.getbean vs @configurable

问题描述

使用 @configurable 与 applicationcontext.getbean 不通过bean管理的 bean bean 的优势相比有什么优势？任何人都可以列出专业和缺点？

解决方案

我将获得 -20 。即使臭名昭着的Martin Fowler发明了这个可怕的依赖注入名称，也没有想到测试更好：

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

人们喜欢依赖注入的常见原因是它使测试更容易。这里的要点是，要进行测试，您需要轻松地使用存根或模拟代替实际的服务实现。然而，依赖注入和服务定位器之间确实没有什么区别：两者都非常适合于stubbing。我怀疑这个观察来自于人们不努力确保他们的服务定位器可以轻松替代的项目。这是连续测试的帮助，如果您不能容易地存储测试服务，那么这意味着您的设计的严重问题。

这是我的反对意见：

1. DI将实现依赖关系转换为接口依赖关系。你的班级被设置者污染，不应该在那里。是的，真正的结帐过程取决于信用卡服务，邮件服务，数据库服务以及谁知道什么是明天，但我们不应该宣传这些依赖关系。它们是特别的，按需的，不是界面值得的。也许下个月，整个结帐流程减少到只是一个REST调用。




2. 性能。一种方法通常不需要服务。 DI每个服务至少需要一个字段变量，只要主机对象存活，它就被引用。如果一个服务有每个客户端状态，这是非常糟糕的。我不是一个表现敏感的人，但这感觉是错误的。




3. 生产环境编码更加困难。想想你每次需要服务时，添加多少个锅炉代码以使用DI。所有以使测试更容易的名义。首先 - 什么？生产是第一优先;测试应该适用于它，而不是相反。 测试不是宗教，人们！关注生产环境，担心以后的测试。第二 - 测试真的很容易吗？




4. 在测试中，您只需要模拟一些繁重的服务，并涉及到VM外的活动。使用服务定位器，您有一个包含这些模拟服务的测试配置，您已完成。您的检查过程可以毫无麻烦地进行测试，以及所有依赖于这些服务的类。在DI中，您必须在每个单元测试中手动管理这些依赖项。 -但！但是使用DI，您可以灵活地为不同的测试单元提供不同的模拟邮件服务！呵呵呵呵呵呵呵呵呵。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。其实与DI无关一个框架执行一种配置方式，您也可以认为，Spring鼓励统一的服务定位方式。当框架变得广泛使用时，它可以成为一个事实上的标准，因此使不同的开发人员彼此之间更容易交谈 - 只是因为网络效应，而不是其设计选择中固有的优点。

总而言之，设计不好，性能不好，生产不好，测试不好，设置标准无关紧要。到底有什么好处呢？这就像很久以前就有很多愚蠢的规则和惯例存在可疑的起源，但是我们仍然每天都盲目地跟着他们。

编辑：转发链接到一个关于DI和测试的新问题使用注释注入依赖关系删除依赖关系的主要好处注入（外部配置）？

what is the advantage of using @configurable compared to on bean that not managed by bean doing di by applicationcontext.getbean? any anyone list pro and cons?

解决方案

I'm going to get -20 for this. Even the infamous Martin Fowler who invented this horrendous name of 'Dependency Injection' didn't think it's better for testing:

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

A common reason people give for preferring dependency injection is that it makes testing easier. The point here is that to do testing, you need to easily replace real service implementations with stubs or mocks. However there is really no difference here between dependency injection and service locator: both are very amenable to stubbing. I suspect this observation comes from projects where people don't make the effort to ensure that their service locator can be easily substituted. This is where continual testing helps, if you can't easily stub services for testing, then this implies a serious problem with your design.

Here are my objections:

1. DI turns implementation dependency into interface dependencies. Your class is polluted with setters that shouldn't been there otherwise. Yes the real checkout process depends on credit card service, mail service, database service and who-knows-what tomorrow, but we shouldn't advertise those dependencies. They are ad-hoc, on-demand, not interface-worthy. Maybe next month the whole checkout process reduces to just a REST call.

2. Performance. Services are usually not needed outside one method. DI requires at least a field variable for each service, and it is referenced as long as the host object is alive. If a service has per-client states this is very bad. I'm not a performance sensitive guy, but this feels just wrong.

3. Coding for production environment made harder. Think how much more boiler plate code you added to use DI, everytime you need a service. All in the name of making testing easier. First of all - what?! Production is the 1st priority; testing should work for it and with it, not the other way around. Testing is not a religion, people! Focus on production environment, worry about testing later. Second - is testing really easier now?

4. In testing you only have to mock a few services which are heavy and involve out-of-VM activities. With service locator, you have a test configuration containing those mock services, and you are done. Your checkout process can be tested without any hassle, as well as all classes that depend on those services. In DI, you have to manually manage those dependencies, in each unit test. -But! But with DI you have the flexibility of providing different mock mail services for different test units now! Oh good for you!

5. "DI encourages a uniform way of service configuration" - only if you use the same framework. Actually it has nothing to do with DI; a framework enforces one way of configuration, you can argue as well that Spring encourages a uniform way of service locating. When a framework become widely used, it can become a de facto standard therefore make different developers talk to each other easier - only because the network effect, not for anything inherently good in its design choice.

In Conclusion, it is bad for design, bad for performance, bad for production, bad for testing and irrelevant for setting standards. What is it good for? It's like a lot of dumb rules and conventions established long ago of questionable origins, but we still follow them blindly everyday. That's what makes the society go around.

edit: forward link to a new question regarding DI and testing Does using annotations to inject dependencies remove the main benefit of dependency injection(external configuration)?

这篇关于使用applicationcontext.getbean vs @configurable的优势的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！