Since dependency injection imply an inversion of control, I can't see an IOC in the following call:
Car car = (Car)ApplicationContext.getBean("car");
It's not Spring to work out itself the class, because I wrote Car myself into the code.
Moreover, all the books talk about two kind of DI: setter and constructor DI.
So I was wondering if the call ApplicationContext.getBean() imply any kind of dependency injection and IOC or there is no DI at all.
No. Getting your bean this way is not dependency injection. It is not getting injected. The fields of that bean are probably injected though.
Sometimes there's really no way around it, but in general, try to avoid this.
It's not Spring to work out itself the class, because I wrote Car myself into the code.
In that case you'd get a NoSuchBeanDefinitionException. You need to tell Spring about every class that it needs to manage -- there are multiple ways to do this, from autowiring to explicit definition in a descriptor.
The getBean does use the same configuration (applicationContext) than Spring's injection would use, but your example is not using any dependency injection. (Well the Car bean could be injected with it's dependencies so we don't really know from your example).
But normally dependency injection means you don't do any programmatic setting (Car car = something ) by yourself. The Spring container will create the car instance for you and either using the car's setters or it's constructor, will inject the dependencies the x needs to work.
I don't know why are trying to get the Car reference in this manner...If you want to use the reference of Car in another class, you can simply use setter or constructor injection as you said..If you use it as in the above manner, I can't see any kind of DI there.One thing we can surely say is that,the bean is managed by the IOC container as you are trying to get the reference from the application context...
Related
I am using Spring and Java 8. I would like to create an aspect or something like that that would set value of my field during object construction, the constructor itsleft validates if the field is not null so the value has to be set accordingly, is it possible with aspects ?
protected MyObject(TimeProvider timeProvider) {
this.timeProvider = requireNonNull(timeProvider, " cannot be null");
requireNonNull(someField, "someFieldcannot be null");
Here u can see that someField is required during creation and not specified in list of fields in the constructor. Thats my specific case.
There is something in the question that doesn't sound right, I'll explain...
Spring AOP indeed allows to create aspects that will wrap Spring beans. They're completely irrelevant for non-spring managed objects.
Now if you're talking about Spring Bean: MyObject then spring will create the instance of this object and inject the TimeProvider - an another bean. If this TimeProvider doesn't exist, spring context will fail to start, thats exactly what you're trying to achieve. You're already using constructor injection so this should work as long as MyObject is a spring bean. Obviously in this case you don't need any aspects, spring will do all the job for you.
Alternatively if MyObject is not a spring bean then spring-aop is completely irrelevant as I've explained.
Its possible to go deeper and analyze how Spring AOP really works and you'll realize that they don't do exactly validations like this, but again, this is rather more advaned discussion than required in order to answer this question
You can use BeanFactory to either
Create new (non singleton) instance of of given class - injection will be done for your
Perform injections on already existing object.
In both cases #Autowire + #NotNull on setter/field should do the trick.
Check https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/factory/config/AutowireCapableBeanFactory.html#autowireBean-java.lang.Object- for example or any other variants.
I read in some posts about Spring MVC and Portlets that field injection is not recommended. As I understand it, field injection is when you inject a Bean with #Autowired like this:
#Component
public class MyComponent {
#Autowired
private Cart cart;
}
During my research I also read about constructor injection:
#Component
public class MyComponent {
private final Cart cart;
#Autowired
public MyComponent(Cart cart){
this.cart = cart;
}
}
What are the advantages and the disadvantages of both of these types of injections?
EDIT 1: As this question is marked as duplicate of this question i checked it. Cause there aren't any code examples neither in the question nor in the answers it's not clear to me if i'm correct with my guess which injection type i'm using.
Injection types
There are three options for how dependencies can be injected into a bean:
Through a constructor
Through setters or other methods
Through reflection, directly into fields
You are using option 3. That is what is happening when you use #Autowired directly on your field.
Injection guidelines
A general guideline, which is recommended by Spring (see the sections on Constructor-based DI or Setter-based DI) is the following:
For mandatory dependencies or when aiming for immutability, use constructor injection
For optional or changeable dependencies, use setter injection
Avoid field injection in most cases
Field injection drawbacks
The reasons why field injection is frowned upon are as follows:
You cannot create immutable objects, as you can with constructor injection
Your classes have tight coupling with your DI container and cannot be used outside of it
Your classes cannot be instantiated (for example in unit tests) without reflection. You need the DI container to instantiate them, which makes your tests more like integration tests
Your real dependencies are hidden from the outside and are not reflected in your interface (either constructors or methods)
It is really easy to have like ten dependencies. If you were using constructor injection, you would have a constructor with ten arguments, which would signal that something is fishy. But you can add injected fields using field injection indefinitely. Having too many dependencies is a red flag that the class usually does more than one thing, and that it may violate the Single Responsibility Principle.
Conclusion
Depending on your needs, you should primarily use constructor injection or some mix of constructor and setter injection. Field injection has many drawbacks and should be avoided. The only advantage of field injection is that it is more convenient to write, which does not outweigh all the cons.
Further reading
I wrote a blog article about why field injection is usually not recommended: Field Dependency Injection Considered Harmful.
This is one of the never-ending discussions in software development, but major influencers in the industry are getting more opinionated about the topic and started to suggest constructor injection as the better option.
Constructor injection
Pros:
Better testability. You do not need any mocking library or a Spring context in unit tests. You can create an object that you want to test with the new keyword. Such tests are always faster because they do not rely on the reflection mechanism. (This question was asked 30 minutes later. If the author had used constructor injection it would not have appeared).
Immutability. Once the dependencies are set they cannot be changed.
Safer code. After execution of a constructor your object is ready to use as you can validate anything that was passed as a parameter. The object can be either ready or not, there is no state in-between. With field injection you introduce an intermediate step when the object is fragile.
Cleaner expression of mandatory dependencies. Field injection is ambiguous in this matter.
Makes developers think about the design. dit wrote about a constructor with 8 parameters, which actually is the sign of a bad design and the God object anti-pattern. It does not matter whether a class has 8 dependencies in its constructor or in fields, it is always wrong. People are more reluctant to add more dependencies to a constructor than via fields. It works as a signal to your brain that you should stop for a while and think about your code structure.
Cons:
More code (but modern IDEs alleviate the pain).
Basically, the field injection is the opposite.
Matter of taste. It is your decision.
But I can explain, why I never use constructor injection.
I don't want to implement a constructor for all my #Service, #Repository and #Controller beans. I mean, there are about 40-50 beans or more. Every time if I add a new field I would have to extend the constructor. No. I don't want it and I don't have to.
What if your Bean (Service or Controller) requires a lot of other beans to be injected? A constructor with 4+ parameters is very ugly.
If I'm using CDI, constructor does not concern me.
EDIT #1:
Vojtech Ruzicka said:
class has too many dependencies and is probably violating single
responsibility principle and should be refactored
Yes. Theory and reality.
Here is en example: DashboardController mapped to single path *:8080/dashboard.
My DashboardController collects a lot of informations from other services to display them in a dashboard / system overview page. I need this single controller. So I have to secure only this one path (basic auth or user role filter).
EDIT #2:
Since everyone is focused on the 8 parameters in the constructor... This was a real-world example - an customers legacy code. I've changed that. The same argumentation applies to me for 4+ parameters.
It's all about code injection, not instance construction.
One more comment - Vojtech Ruzicka stated that Spring injects beans in such three ways (the answer with the biggest numbers of points) :
Through a constructor
Through setters or other methods
Through reflection, directly into fields
This answer is WRONG - because FOR EVERY KIND OF INJECTION SPRING USES REFLECTION!
Use IDE, set breakpoint on setter / constructor, and check.
This can be a matter of taste but it can also be a matter of a CASE.
#dieter provided an excellent case when field injection is better. If You're using field injection in integration tests that are setting up Spring context - the argument with testability of the class is also invalid - unless You want to write later on tests to Your integration tests ;)
Everybody knows that #Autowired(#Inject etc) annotation is processed by AutowiredAnnotationBeanPostProcessor. It parses and set fields and setters annotated with #Autowired but what about constructors? This is bean PostProcessor, that means that it is called after bean was already created, but constructors can also be marked as #Autowired, so how such beans are created?
Good question. For clarification's sake, to re-word it:
How does Spring provide the capability to do dependency injection on
constructor parameters when it seems like dependencies are injected
only after the bean is created?!
If you look at the AutowiredAnnotationBeanPostProcessor you'll find that there is a method called #determineCandidateConstructors that doesn't get called anywhere from inside that class itself.
The reason it's not called there is because it's referenced in the AbstractAutowireCapableBeanFactory; a class that's used for the actual creation/instantion of the bean!
I would imagine Juergen and the Spring guys decided it made architectural sense to put the #determineCandidateConstructors in the AutowiredAnnotationBeanPostProcessor class because it fits in with the concept function of the real purpose of Autowire-ing an injected dependency.
FYI, these concepts of field #Autowire vs. constructor #Autowire is so tightly tied together, that there is a whole discussion in the Spring DI world on whether to use constructor vs. dependency injection. See the section entitled Constructor-based or setter-based DI of this article, Oliver Gierke's comment (i.e. head of Spring Data project), and google for more information.
Spring's DI works fine for singleton scope bean. However, regarding to prototype scope it is not convenient if the prototype bean itself will inject other beans. The thing is for prototype bean, I would like to create them using new keyword of Java with runtime constructor arguments which is hard to be statically described in XML bean configuration. Using new keyword makes the prototype bean out of Spring container, it is impossible to use Spring DI in them of course.
I am wondering how people solve problem like this? Of course I can use AspectJ to do myself injection as a compensation. But having two injection mechanisms is not an elegant solution to me.
You should be able to create prototype objects through context.getBean(name) or context.getBean(class) where context is ApplicationContext instance.
Another, perhaps even more convenient way is to use factory pattern with factory object being a singleton with all dependencies wired in and passing them to the constructed objects in factory.createInstance(...).
Mark you prototype bean with #Configurable
Spring allows for passing constructor values to the getBean() method, check out this SO-Post:
spring bean with dynamic constructor value
Furthermore, what would be wrong about retrieving a bean from the context, that is just partially initialized and you are setting the runtime-parameters yourself via setters?
Be aware, that Spring-Beans are by default Singletons, so in your Spring-Config you would have to explicitely specify them as being prototype-scoped!
I am trying to let a piece of runtime state decide WHICH implementation of an interface to use, preferably solely by autowiring.
I have tried making an object factory for the interface thet uses dynamic proxies, and I used qualifiers to coerce the #Autowired injections to use the factory. The qualifiers are necessary because both the factory and the implementations respond to the same interface.
The problem with this is that I end up annotating every #Autowired reference with the #Qualifier. What I'd really want to do is annotate the non-factory implementations with something like #NotCandidateForAutowiringByInterface (my fantasy annotation), or even better make spring prefer the single un-qualified bean when injecting to an un-qualified field
I may thinking along the totally wrong lines here, so alternate suggestions are welcome.
Anyone know how to make this happen ?
You could use #Resource and specify the bean name of the factory.
I haven't looked at this myself but I noticed Spring JavaConfig is made it to M4 and it seems to allow more flexible configuration through a combination of annotations and Java code. I wonder if it would offer a solution to your problem.