IoC and Convention Over Configuration/DRY - the real power of Java EE 5 📎
I do not really make a difference between Java-Code and XML. In production you have to maintain both items in a (SVN) repository
and it is very unlikely that someone will change things in a dynamic way. And you have also to maintain two artifacts (source and XML)
in parallel with some redundant information which is not DRY (Don't Repeat Yourself).
Java EE 5 does not require XML-configuration and uses annotations instead. From the Separation Of Concerns perspective it is
not very clean, but pragmatic. To use an EJB B from an EJB A you have only to provide the @EJB annotation.
It looks like:
public class BeanA {
@EJB //reference name and type inferred from member
private BeanB b;
public void hello(){
b.helloPlease();
}
}
The overhead here is the annotation @EJB. The type and name are automatically inferred - so here is no need to specifiy this redundant information in (redundant)
external XML-files. But it is still possible, you are still able to override the default using XML.
The cool story here: the reference is injected directly into the private member. This violates a little bit the principle of private :-), but is also
very pragmatic, convenient and lean. Setters/getters are evil so are not needed any more... If you like you can of course go the old way and use setter/getter injection instead
the direct flavor (e.g. for debugging purposes).
So IoC with the notion of DRY and Convention Over Configuration are really powerful and very lean. If you like to see IoC in action just try Java EE 5 :-).
Actually it is only a syntactic sugar, behind the scenes, JNDI lookup etc. is still used.
I see the real benefit of IoC in combination with Convention Over Configuration, but I still do not see an advantage of using accessor based IoC with external (XML) configuration files.