What’s the right way to do IoC ?

28 09 2007

When we talk about IoC, there is a vast spectrum of IoC complexity that we are willing to accept. Those who love Spring IoC in XML will create 1000’s of lines of XML and proudly show 5 lines of Java. On the other end of the scale there are those that IoC 2 or 3 large beans to represent the exposed bean. Which is right or better ? I have no idea, both are probably right depending on your religion. Here are some observations.

Static Factory patterns are a complete pain, make it hard to unit test and eliminate most deployments options, hence why we use IoC.

Manual construction of large bean structures prior to resorting to IoC reduces configuration post distribution but reduces the complexity of the deployed exposed beans. It also, is compiled and so the structure can be largely validated at compile time. This is still IoC, its just IoC using fixed method calls rather than invoked by some IoC management framework. So manual in code IoC simplifies what is exposed to the deployer and makes the configuration of the component more reliable.

On the other hand, doing all the IoC within Spring XML maintains flexibility, but increases complexity and delays much of the validation until the runtime. Excessive Spring XML is effectively programming in XML, and should not be confused or excused as not lines of code. Its all code. The positive side of this approach is the end result is highly configurable and customizable, but on the down side its almost impenetrable except by the author, and sometimes on the day they wrote it. So heavy use of XML IoC can de-stableize the deployment packages and confuse all but the authors with unnecessary detail.

So as I test I did both, I have about 50 beans that are reused multiple times and use pure getter setter IoC. There is only 1 new() in all the bean code. I constructed Unit tests with in code IoC in the test case classes. In general it takes about an hour to construct the work from scratch doing manual edits in eclipse. Then for production I did a pure spring XML file. This has taken about 14 hours to construct so far even with SpringIDE in eclipse. Maybe I am a slow typist, or SpringIDE isn’t helping me enough, but the lack of edit time validation the subtler details of the XML and the final validation at runtime appears to be slowing the development cycle.

I will stick with the Spring XML for this component, but it makes me wonder if there is a better way. Google Guice uses @Inject annotations and Models to do all the IoC directly in the code. Its clearly now as wide as Spring…. but it looks much easier to simple IoC and eliminates all the XML files.

Whatever the right way is, it has to allow the developer to cycle fast and make progress.

Advertisements

Actions

Information

5 responses

28 09 2007
Lance Speelmon

I think Spring will let you use annotations now as well… I would hate to lose all of the 3rd party compatibility with Spring to get simplicity from Guice. Maybe there is a happy medium with Spring and annotations… L

28 09 2007
Ian Boston

Yes, you are right it does, there is a comparison (by the author of a spring book) here http://www.jroller.com/habuma/entry/guice_vs_spring_javaconfig_a

Not surprisingly it comes out 3 5 to Spring …. but thats with annotations.

Incidentally 18 hours later a 50 bean injection is working. If it was like this every time, I would go to the spring conferences and heckle from the back…. fortunately its not quite that bad…. it does remind me of C++ COM development 🙂

4 10 2007
Antranig Basman

Doing IoC in code is just fine… also Spring are exploring other approaches of constructing the container in DSLs other than XML – there is a Java one here http://blog.interface21.com/main/2006/11/28/a-java-configuration-option-for-spring/, and a “Groovy Bean Builder” here http://grails.org/Spring+Bean+Builder . I saw a post once with a really compact “pure DSL” as well, can’t find the link at the moment.

These are all fine, but to me the Guice-style annotation solutions miss the point that the whole point of IoC is to keep the configuration *out* of the code! By all means write the IoC stuff in something other than XML, but at least write it somewhere *else*…

19 10 2009
Ke Jin

IoC containers are not “to do” IoC, they simply use IoC to do the non-programmatic deployment. This is just like their predecessors (old EJB that used service locator design) were not “to do” service locator, but just used it as the core design.

In another word, it is not IoC containers help you to do IoC, but IoC design helps IoC containers.

New DI frameworks, such as guice, confused this by changing the subject from “using IoC/DI as the core design of containers” to “using containers to program IoC/DI design”.

20 10 2009
Ke Jin

IoC containers are not “to do” IoC. They just “used” IoC as a mechanism to support a non-invasive, non-programmatic deployment/configuration model.

If your only purpose is “to do” IoC, you should not use those XML based IoC containers but some programmatic DI frameworks. They seems to be similar, but are apples and oranges.




%d bloggers like this: