Does it makes sense in Spring to use #Autowired to wire directly to a concrete class and not to an interface (and make use of 'by type' autowiring)
If a class doesn't implements an interface wouldn't it be better to instantiate it via constructor or a factory (keeping things simple); rather than make it a Spring bean just for the heck of it.
Does it makes sense in Spring to use #Autowired to wire directly to a concrete class and not to an interface
Sure. The practice of autowiring is independent of what you're autowiring. It'll work with classes just as well as interfaces.
However, whether or not it's a good idea is debatable, although this is a more general question of whether you should always introduce an interface for a given class, rather than talk directly to the class type. The benefits include easier unit-testing and a cleaner design, at the expense of code clutter.
There's another good reason to autowire interface types rather than class types, which is that if Spring needs to generate a proxy object around the bean before injecting it, then if the bean's class defines any interfaces, then the proxy will implement those interfaces, and will not be type-compatible with the bean class itself. If you then try and autowire that bean by class type, it will fail. The easiest way to avoid this annoying scenario is to always autowire by interface type, that way it will lways work as you expect.
and make use of 'by type' autowiring
If you mean container-level byType autowiring, then you don't want to do that. It's the old Spring 1.x style of autowiring, and it's highly inflexibile (see limitations of autowiring).
Stick with #Autowired, it's much more flexible and easier to control.
If a class doesn't implements an interface wouldn't it be better to instantiate it via constructor or a factory (keeping things simple); rather than make it a Spring bean just for the heck of it.
The two questions are completely separate. An object should be made a Spring bean if you need Spring to control its dependencies and lifecycle, regardless of whether or not it implements interfaces. If you find that the object has no dependencies, and no meaningful interface, then perhaps there is no reason to make it a bean.
You will have to decide if hardwiring this dependency into other classes is ok. For instance, how many different classes are likely to require this dependency? If the answer is many then you will be creating many instances of this class where only one is required.
Also, what dependancies does this concrete class have? You will have to configure those inside the class that depends on it.
The object of dependency injection is to reduce the dependencies between classes and make your code loosely coupled.
Related
In an interview, I have been asked a Question:
In spring, what is the use of an ApplicationContextAware interface ?
Performing Dependency injection
Makes bean aware of the container
Both of these
None of these
As per my knowledge, as well as per few articles , I think Option 2 is correct.
Please let me know if ApplicationContextAware interface also helps in Performing Dependency injection.
According to Docs, Its main/only goal is that class which is implementing this interface requires access to a set of collaborating beans.
https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/ApplicationContextAware.html
I think the interface's name is self explanatory, so yes it makes the bean aware of the container.
The dependency injection is performed by the framework through multiple ways, but most of them use the #Autowired annotation, so you could start reading about it.
Can I know what is the difference between dependency injection and autowiring? Whether autowiring is different from dependency injection?
Which is the best way to autowiring(XML based or annotation based)?
Short answer: Dependency Injection is a design pattern, and #autowired is a mechanism for implementing it.
The DI idea is that, instead of your object creating an object it needs (say by using new to instantiate it), this needed object - a dependency - is handed to your object, typically using the constructor or a setter method. If you autowire, you're injecting a dependancy. In this case, Spring uses reflection to make this work, so you're not using the constructor or a setter method, but you're still injecting the dependency.
To answer question 2, its your choice. Personally, I find the XML configuration files cumbersome and use annotations whenever I can. You can accomplish whatever configuration you need to do either way.
I'm currently trying to configure Spring Boot (using Java Annotations and ComponentScan) for the following scenario:
Scenario
There's an interface MyService.
I want to provide a default implementation for MyService, let's call it MyDefaultService.
If the component scan detects no other implementation for MyService, Spring should instantiate MyDefaultService as a "fallback".
If there is a different implementation of MyService present, let's say MyCustomService, then that bean should always take precedence over MyDefaultService when autowiring a dependency to MyService. In that regard, MyDefaultService should be recessive (as opposed to #Primary).
Ideally, there should not need to be an additional annotation on MyCustomService to have it "override" MyDefaultService.
Ideally, no explicitly implemented factories or factory methods should be required.
Question
The question is: how do I need to annotate the MyDefaultService class in order to achieve this?
What I tried so far to solve the problem
Annotating MyDefaultService with #ConditionalOnMissingBean(MyService.class). Didn't work because MyDefaultService is never used, even if there is no other implementation of MyService.
There is an annotation called #Primarythat solves the problem. However, it needs to reside on MyCustomService, a class that I try to keep free of additional annotations. Essentially, I need the inverse annotation of #Primary on MyDefaultService. However, I couldn't find such an annotation.
Concrete use case
I am developing a service layer in one project, and a different project will implement a web UI layer on top of it. The UI project has a dependency to the service layer project. However, for certain functionalities implemented at the service layer, I need to know which user is currently logged in at the web context. So I have to define a service interface for that in the service layer project, such that it can be implemented by the UI project. However, for testing purposes in the service-layer project, I need a default implementation of that interface. Also, in case that the UI project team forgets to implement this interface, the app should not crash, but instead instantiate the fallback bean and issue a warning.
Thanks & kind regards,
Alan
I suggest writing an implementation of FactoryBean to do this. Your FactoryBean would scan the bean factory looking for beans that implement MyService, and if it finds one it returns that bean from getObject. If it doesn't, then it can instantiate MyDefaultService directly and return that. Your factory bean then gets annotated with #Primary.
So pieces like this (pseudo-code):
public class MyServiceFactory implements FactoryBean<MyService> {
ListableBeanFactory beanFactory;
public MyService getObject() {
Map beans = beanFactory.getBeansOfType(MyService.class)
if (beans.isEmpty())
return new MyDefaultService(); // plus args, obviously
else
return get_some_bean_from_the_map
}
}
and then
#Primary
#Bean
public MyServiceFactory MyServiceFactory() {
return new MyServiceFactory();
}
Spring will automatically handle the factory bean (i.e. it will make the MyService object available as a bean for injection like normal.
This solution doesn't require any special magic, and it's fairly obvious how it works. You can also handle errant cases such as multiple MyService beans being declared.
I'm a fresher, I'm recently started learning Spring.In spring dependency injection,we
can inject a bean in 2 ways,one is through constructor and the other one is through
setter method.My question is, for what situations constructor injection is better and
for what situations setter method injection is better. my focus only on where to use?
Give me an example if possible... waiting for your valuable reply..
There is a third way: Field injection.
You can directly apply the Annotation #Resource, #Inject or #Autowire at a (even private) field. This field even does not need to hava a getter or setter.
If you are building a Spring application, and there is no plan to use the classes in a not Spring application or a library, then the field injection is enough for 90% of the classes.
I prefer it, because it is less code.
Of course if you use a constructor for mandatory references then there is no way to forget one of them when creating a new instance. But (and this is my point of view, that differs from Alef Arendsen in his 3 year old Spring 2.0 blog entry "Setter injection versus constructor injection and the use of #Required") you have a spring bean and not a simple class. And this bean is created by spring, not directly by you. So if you use #Resource, #Inject or #Autowire for fields or setter spring checks them too and do not put the bean and the whole application in service if not all references can be satisfied.
I'd say go for constructor injection.
In some cases go for setter injection if dependency is optional.
If you forced to use setter injection and use Spring, the use #Required to ask Spring to enforce it.
Apply common sense in all cases :)
As in the title above, I am confused about pros cons between injecting applicationContext by directly #Autowired annnotation or implementing ApplicationContextAware interface in a singleton spring bean.
Which one do you prefer in which cases and why? Thanks.
Actually, both are bad. Both of them tie your application to the Spring framework, thus inverting the whole inversion-of-control concept. In an ideal world, your application should not be aware of being managed by an ApplicationContext at all.
Once you have chosen to violate this principle, it doesn't really matter how you do it. ApplicationContextAware is the legacy version that has been around at least since Version 2.0. #Autowired is a newer mechanism but they work in pretty much the same way. I'd probably go with ApplicationContextAware, because it semantically makes clear what it is about.
As #Sean Patrick Floyd says, the need of ApplicationContext is often due to a bad design. But sometimes you have no other option. In those cases I prefer the use of #Autowired because is the way I inject all other properties. So, if I use #Autowired for injecting MyRepository, why can't I use it for ApplicationContext or any other Spring bean?
I use Spring interfaces only for those things I can't do with annotations, for example BeanNameAware.
If you need to get a prototype in a singleton then you can use method injection. Basically, you create an abstract method that returns the object you need and spring will return the prototype everytime you call that method. You define the "lookup-method" in your spring config. Here are some links:
http://docs.spring.io/spring/docs/1.2.9/reference/beans.html#beans-factory-method-injection
http://java.dzone.com/articles/method-injection-spring
Since you are not extending any of the spring classes your application is always separated from the framework. Most of the cases you will not wanted to inject the ApplicationContext as it, but will need to inject the beans defined in the ApplicationContext.
The best case is always to stick to the bare minimum, until and unless you have any specific requirement and this is very simple with spring.
So either,
Annotate your beans and scan them in application context, then use #Autowire to wire them up.
Use application context to wire your bean expediencies(old xml style configs). You can use #Autowire with this approach also.
When you want to control the bean life cycle, you can read the API and customize it, but most of the time these general settings will do the job.
Here are some examples.
Spring Auto-Wiring Beans with #Autowired annotation
Spring Auto-Wiring Beans XML Style
Spring IoC container API Docs
There is no need to use ApplicationContext at all.
ObjectFactory
If you need to use prototype scoped beans in a singleton bean, inject an org.springframework.beans.factory.ObjectFactory.
For example using constructor injection:
#Service
class MyClass {
private ObjectFactory<MyDependency> myDependencyFactory;
public MyClass(ObjectFactory<MyDependency> prototypeFactory) {
myDependencyFactory = prototypeFactory;
}
}
Why
Now what's the benefit over using ApplicationContext ?
You can substitute this dependency (e.g. in a test) by simply passing a lambda (since ObjectFactory is a #FunctionalInterface) that returns a stubbed version of it.
While it is possible to stub the ApplicationContext, it is not clear in that case which beans will be looked up and need to be stubbed.