0

I was going through the spring documentation, and came across the following statement-

You can then use getBean to retrieve instances of your beans. The ApplicationContext interface has a few other methods for retrieving beans, but ideally your application code should never use them. Indeed, your application code should have no calls to the getBean() method at all, and thus no dependency on Spring APIs at all. For example, Spring’s integration with web frameworks provides dependency injection for various web framework components such as controllers and JSF-managed beans, allowing you to declare a dependency on a specific bean through metadata (e.g. an autowiring annotation).

Ref-https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html

In my application, I receive some parameters to my client method, based on Which, I inject proper implementation of Interface. The way I do it is, to search for the bean id after concatenating those parameters. For example- if I receive type=C, subType=D, I get the bean with bean id=typeCsubTypeD by calling getBean(beanId). i.e, my dependencies are decided on Run time.

I have gone through Why is Spring's ApplicationContext.getBean considered bad?

But, this does not cover my use case (as also addressed by a comment in that question).

Deb
  • 5,163
  • 7
  • 30
  • 45
  • interesting question, could you share the code? what's the way parameters come in? – Andrew Tobilko Oct 20 '17 at 21:19
  • My project is used as a jar library in another application. That application call the methods of this jar. Now based on what parameter it passes I have to select the bean and produce the result. – Deb Oct 21 '17 at 05:32

1 Answers1

2

Generally, my advice would be to avoid flavor-of-the-month fanatics.

Nowadays, inversion of control is very much the hype (as part of the SOLID design principles), so if anyone uses anything that goes against that principle, people will blindly bash it and says that you should avoid using it. However, the real answer is that there are no universal laws when it comes to software design. If you have valid reasons for not using inversion of control in your application, then you are most certainly fine with using getBean(). What the principle is generally meant to mean is "don't use getBean() in static initialization contexts where you can use inversion of control instead".

For example, we have an application that uses Spring as a "bean scripting language" to allow non-developers to define configurable Java beans without using a full-fledged DSL. If you are using Spring in that respect, then there is no reasonable way that you can avoid using getBean().

Piotr Wilkin
  • 3,446
  • 10
  • 18
  • How does getBean() goes against IoC? Because, I am still creating bean using Spring container (not by the dependent class) and getting the bean at run time. Its just that, dependency is not resolved at compile time. – Deb Oct 21 '17 at 05:30
  • 1
    Since you're relying on an `ApplicationContext`, unless the context itself is injected, it's no longer fully IoC because you have to know how to get the context itself. There is a good discussion under the post you linked about the difference between service locator and IoC and the use case you mentioned is more of a service locator one than pure IoC. – Piotr Wilkin Oct 21 '17 at 12:19