I was trying to understand dependency injection and I am trying to figure out if its possible without creating interfaces?
If yes, than how can we call different beans as per the need?
Related
I am new to spring Boot and i was trying to learn the differences between different dependency injection techniques.
Is there any scenario where dependency injection through field is always prefered over constructor or setter injection?
I read that field injection is always a bad practice.
If its bad then why we still do it?
Short answer: there is no info about that.
Long answer:
It's strange that spring docs don't even mention field injection in any way
DI exists in two major variants, Constructor-based dependency
injection and Setter-based dependency injection.
I haven't found any info about when field injection is preferred over two aforementioned ones, besides the time where you do not need any of the benefits of CBDI and SBDI(for example, easier testing and NPE avoidance) and you want to keep your code short, but even this argument becomes obsolete if you use Lombok. Why does this feature even exist in the first place, IMHO:
1.There was a bad design choice that lead to it's creation and use in production(Spring Framework's first version was published back in 2002 and probably there was no any debate about whether or not field injection is a bad practice at that time)
2.Backward-compatibility stopped from removing this feature because it could break already existing codebase.
Modern Spring recommendations (Spring 4.x onwards) recommend not using field injection (with #Autowired or #Inject), and instead preferring constructor arguments. Several discussions about this here, here and the Spring Framework itself recommends constructor-based DI for mandatory dependencies.
In general I agree perfectly with the rationale, and in fact I haven't used any of the field injection mechanisms for years now.
What is bugging me however is the way we inject Spring Data Repositories. Of course these are mandatory dependencies, the service needs them to work. When one looks at the Spring Data documentation one finds that the reference documentation itself is using #Autowired field injection all over the place, precisely what was recommended as bad practice in the Spring Framework documentation itself.
Of course, it is no problem to have repositories use constructor injection. I have been using this for quite some time. However, sometimes components and services need quite a number of repositories. A service might be interacting with 7 or 8 database tables, and they would need to be in the same transaction.
How does one go about this to have neat code? Using constructor arguments is the safer approach, but leads you to have a huge number of constructor arguments. Setter injection does not seem to fit, these are not optional dependencies. Field injection is supposed to be plain wrong (even though the Spring Data doc uses it).
Is there any other approach one could use? I was tempted to aggregate related repositories in a separate #Component, at least the service constructor gets only one argument with this constructor. It does help a bit, but makes it even harder to interact with a new table (the new repository would need to be added to the aggregate, and the service would need to call the getter for it).
How is it supposed to be done neatly without violating any safety recommendations and adhering to coding standards (few constructor arguments etc.)?
I'm providing a Spring RestController as a part of a library. Currently I have reusable jaxrs services, but I need to make Spring Boot alternatives. One RestController for example has 2 dependencies: one is a service that I could see being a bean and the other a String property.
I'm wondering what is the idiomatic way to expect to get those dependencies from users consuming the library. I had a few ideas about how it might happen, but wasn't sure what was the right or at least best practice way to do it.
Should users construct the RestController manually using the constructor (not using dependency injection)? I actually couldn't even figure out how to do this such that the Spring Boot Application knew about it and didn't see it in guides, so I was assuming this isn't the normal way to provide RestControllers. I only wondered if this was the right way to go as dependency injection being used for a third party library class's dependencies seems like it could be hard to manage.
Should both be beans, with the String property being a named bean? I have this one working, but I'm wondering if consumers of the library having to provide beans that the library's RestController expects is tricky or a bad practice.
Should the simple service be a bean and the String injected via #Value?
Is there some alternative or better way?
guys
As i know ,Dependency injection is a implementation of Ioc
But I am not clear about the relationship between dependency lookup & Ioc
,Is dependency lookup also a implementation of Ioc.
Can anyone help this? thanks!
I'm no spring expert, but my £0.02.
Dependency injection is externalisation of provision of dependecies.
Dependency lookup is centralisation of provision of dependencies.
with DI the dependencies something has are provided to the object by something else, ideally when the object is constructed. This may or may not involve a framework.
Dependency lookup is when the object itself tries to create the dependencies it needs using some generic service. In spring I believe this is effectively asking Spring for the type of object it needs and the container resolving the object type there and then (ref).
This is effectively the ServiceLocator (anti-) pattern (more details). Although not everyone is convinced its an anti pattern
IMHO you should strive to use DI in all cases and should not use dependency lookup at all.
Can anyone shed some light on the advantages and disadvantages of using a custom ActionInvoker like so to perform dependency injection on custom ActionFilters as opposed to using a custom FilterProvider as demonstrated here?
In both cases you are going to still want to avoid constructor injection on your ActionFilters, and to me it seems that all the custom FilterProvider does in this case is adds additional overhead of having to register your ActionFilters and the provider in your container.
The big advantage of filter providers is that it allows constructor injection if done right. The example you linked does not demonstrate this correctly. To use constructor injection you can not use filter attributes. Instead you have to separate the two things the declaration that you want to apply a filter (e.g. using an attribute) and the filter implementation.
I'm not sure if there is a good implementation for Unity. See on http://www.planetgeek.ch/2010/11/13/official-ninject-mvc-extension-gets-support-for-mvc3/ how it could feel like. But this is a Ninject example. Probably you can take its implementation on github and port it to Unity.