This week's book giveaway is in the Python forum.
We're giving away four copies of Python Continuous Integration and Delivery and have Moritz Lenz on-line!
See this thread for details.
Win a copy of Python Continuous Integration and Delivery this week in the Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
Sheriffs:
  • Devaka Cooray
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Tim Holloway
  • Claude Moore
  • Stephan van Hulst
Bartenders:
  • Winston Gutkowski
  • Carey Brown
  • Frits Walraven

Depndency injectsion types , how to choose ?  RSS feed

 
Ranch Hand
Posts: 198
1
Java Python Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Craig,

  With many of options available via XML configuration, Component scanning, and auto wiring, @Inject annotation,
  what would be your advice and the best practice to choose the best DI mechanism suitable for a given situation in Spring?


Thanks
Sundar
 
author
Posts: 396
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To some degree, it's a matter of individual taste. But I prefer...in this order...

1. Spring Boot autoconfiguration for any configuration that is essentially boilerplate.
2. Component-scanning/autowiring (e.g., @Component/@Controller/@Repository/@Service/etc and @Autowired) for the beans whose code is in my control.
3. JavaConfig (e.g., @Bean methods) for beans that aren't covered by #1 and #2
4. XML almost never...usually only when I'm (temporarily) leveraging some existing config that is already written in XML.

I never use @Inject, but if you like it, then it's a suitable alternative for @Autowired.


meenakshi sundar wrote:Craig,

  With many of options available via XML configuration, Component scanning, and auto wiring, @Inject annotation,
  what would be your advice and the best practice to choose the best DI mechanism suitable for a given situation in Spring?


Thanks
Sundar

 
Saloon Keeper
Posts: 20498
115
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This isn't just Spring, but the convention these days is that you can do your configuring and wiring via annotations, and then use XML as an override, if needed.

Before annotations, XML was the preferred way to do that kind of stuff (either that or property files), but it was a royal pain because you were constantly switching back and forth between the Java source and the XML config files in your editor session. Annotations got rid of that requirement by allowing meta-information to be stored directly with the Java source. So you only had to edit in one place and not 2, and thus, not only saved effort, but were a lot less likely to get out of sync.

However, XML was kept because sometimes you don't want the standard information. This is especially true if you're trying to re-use code in a different environment or if you want 2 instances of the same bean class, but need them to be cataloged under different bean names. Without some sort of override mechanism, you'd have to physically edit the Java files. With XML overrides, you can make a small XML file with just the override data in it and leave the bulk of the metadata to the stock annotations. And the original Java source code remains unchanged.

The @Inject annotation was developed for CDI and the last time I looked at trying to make Spring and CDI work together in a JSF webapp, I found CDI to be lacking so I kept to the original JSF and Spring annotations. Admittedly, that was some time ago and things may be better now, but at the time I had the impression that some basic characteristics between the 2 frameworks were in conflict.
 
meenakshi sundar
Ranch Hand
Posts: 198
1
Java Python Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

To some degree, it's a matter of individual taste. But I prefer...in this order...

1. Spring Boot autoconfiguration for any configuration that is essentially boilerplate.
2. Component-scanning/autowiring (e.g., @Component/@Controller/@Repository/@Service/etc and @Autowired) for the beans whose code is in my control.
3. JavaConfig (e.g., @Bean methods) for beans that aren't covered by #1 and #2
4. XML almost never...usually only when I'm (temporarily) leveraging some existing config that is already written in XML.



Appreciate your answer, though you say it is up to the individual's personal preference,
you must be having some reason for your choice...
 
Craig Walls
author
Posts: 396
8
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

meenakshi sundar wrote:[
Appreciate your answer, though you say it is up to the individual's personal preference,
you must be having some reason for your choice...



Sure, let me expand on that a bit:

1. I prefer Spring Boot auto-config over any other option because why should I write configuration if I don't have to? Every single line of code, whether it be business logic or configuration is a liability. If I can get the same benefit from writing no configuration and letting Spring Boot handle it for me that I can get from writing explicit configuration, then I will have less liability if I let Spring Boot do the work.
2. I prefer component-scanning and autowiring over the remaining options for a similar reason. If by simply putting an annotation on a class I can suddenly make Spring manage its lifecycle and dependency injection, then that's better than me explicitly writing configuration to do the same thing. Also, if I write any explicit configuration for components that I also have to write, I find that there's at least a tiny bit of duplication (at very least in the type name) and I must make sure that any refactoring I do on the component is also reflected in the configuration (IDEs usually are good at that, but all the same...).
3. I prefer JavaConfig over XML because I do get all of the benefits of Java--type-safety, IDE support for refactoring, testing, and I have the option of even writing some logic into my configuration--that I don't get with XML config. But generally I only resort to explicit JavaConfig if neither 1 or 2 are an option...or, in a more rare circumstance, I find myself writing Boot autoconfiguration for a library so that someone else can benefit from it.
4. I avoid XML configuration at almost any cost, primarily  because of the benefits afforded by the other 3 options. Although I never hated XML configuration when that was the norm, I must admit now that viewing XML configuration makes my eyes hurt. As I said before, though, I might still use @ImportResource to link in some existing XML configuration that I'm not ready or interested in rewriting into JavaConfig.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!