CDI 1.0 vs. Spring 3.1 feature comparsion: bean definition & dependency injection
Email
This blog article provides a comparison matrix between Spring IoC 3.1 and CDI implementation JBoss Weld 1.1. Comparing the two technologies is difficult 'cause it happens easily that you compare apples to oranges. I have asked myself a lot of questions before I have started the comparison effort:
- Which direction is best for comparison: from CDI features to Spring features or vice versa?
- What is a feature and which features should one choose for comparison?
- What's the appropriate level of abstraction for comparison?
- Which features are important?
- Will I use Spring or CDI terminology or will I have my own abstract feature requirements?
- For the CDI implementation: which implementation to choose, Weld, Apache OpenWebbeans or Resin CanDI?
- Can I build groups of features?
I have decided to build my own list of abstract requirements for an IoC container. Furthermore I think a good way to start the comparison is to only look at the "pure" bean definition and dependency injection features provided. The advanced stuff like CDI Interceptors or Decorators is covered ín subsequent articles. I have chosen Weld as the CDI implementation because it provides the best documentationcompared to the other implementations, also Weld is the reference implementation for JSR 299. With regards to the particular features compared: I have chosen features that I found important from my own history as a developer in large projects, and yes! of course that's subjective. There will be other features that you may find more important, feel free to add comments and I will adjust the matrix if appropriate.
To outline the scope of this analysis and for those that like to dive deaper into the topic, it's a good idea to be concrete about the reference for this comparison:
Spring 3 reference dosumentation refered to:
- Chapters 3.2 to 3.4: Container Overview, Bean Overview, Dependencies
- Chapters 3.9 to 3.12: Annotation-based container configuration, Classpath scanning and managed components, Java-based container configuration
Weld 1.1 reference documentation refered to:
- Chapters I.1-I.4: Introduction, More about beans, Dependency injection and programmatic lookup
- Chapter III.8: Producer methods
Why comparing CDI and Spring is not particular easy
Spring offers three different approaches to do dependency injection: XML-based, annotation-based and pure Java-based (programmatic). CDI on the other hand is strictly annotation-based. Therefore the easiest way to compare the two is: "Spring's component scanning and autowiring" vs. CDI. These concepts play in the same sand box - from a technological view point. On the other hand one may say that XML-based (or programmatic Java-based) configuration provide critical benefits. Therefore I have not distinguished the three different approaches in Spring, I just looked at the features provided.
Spring is a framework that provides lots of functionality that is integrated into the IoC container. Comparing all the stuff with CDI does not make sense, because in Java EE lots of the functionality of the Spring IoC container is covered in other API, seperate from (but also integrated into) CDI.
A summary of what I think is true
From a pure feature oriented-perspective: in the area that I compared in this article, there is only little critical difference in the two technologies. Spring offers three different IoC container configuration approaches: XML-based, Annotation-based and pure Java-based (programmatic). CDI on the other hand is purely annotation driven. CDI gives you less to think about, it is a very streamlined solution. Spring offers options to fine-tune for your specific requirements. XML-based or programmatic Java-based configuration - for instance - are the only ways for you to have real pure POJO's. Also, the Spring Expression Language adds some noteworthy features (e.g. bean identification and injecting property values). However, both technologies cover the most important dependency injection features.
In the comparison process I have tried some of the stuff with both frameworks. I have to say that I found the Weld reference documentation much more intuative to read. May be that's a consequence if you only provide one configuration approach. On the the other hand I would suggest that Spring reference documentation should structure their chapters according to the three different mainstream approaches (XML, annotations, programmatic). It's a bit confusing that examples are spread across the reference documentation (e.g. if you are looking for type-safe dependency injection using annotations). The three approaches are the obvious documentation structure, because end users first decide which approach to use
Note that I was doing feature comparison here. There is more to think about then just features. See my two blog entries on technology decision making and JEE vs. Spring comparison.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
No comments:
Post a Comment