I found this video introduction on Guice very good. Guice is another Inversion of Control (IoC) container, much like Spring IoC, but with the advantage of coming later. What's particularly interesting about Guice is that it largely forms the basis of JSR-299's IoC.
I'm a big user of Spring IoC and frankly don't have a problem with it. However I can see that Guice could save me some wiring code and, therefore, potentially bugs (not that there are bugs in my code!). I might well consider using Guice for future projects. The outcome of JSR-299 will weigh in heavily on this decision though as I like my code to be as standards-compliant as possible.
One thing that I am comfortable about with Spring though (vs Guice) is that my beans have no knowledge of being injectable; they simply are by being bean conforming. With Guice you must declare what is potentially injectable. I do like the loose coupling between my bean code and the IoC that Spring provides, yet I can see that Guice, by declaring what is injectable, can save some of the wiring code.
I'll guess I'll just have to give Guice a whirl to find out.
skip to main |
skip to sidebar
This is my blog where I like to focus on things of a software development nature.
2 comments:
The outcome of JSR-299 will weigh in heavily on this decision though as I like my code to be as standards-compliant as possible.299 looks controversial and seems to lack focus (read the jsr original summary). These are not recipes for wide adoption More on this...Btw do we really need to standardize IoC? The benefit of IoC is realized when the framework deals with true POJOs (as per your previous post's definition if you will), in effect removing the need for a strong/explicit contract between the beans and the IoC framework then reducing the value of standardization (to wiring configuration?). I reckon IoC frameworks can compete at the pattern level, not all patterns need their very own jsr.
I agree with you on everything. In fact your comment resonates with my original one in response to JSR-299. :-)
However I do see that standardising the IoC annotations can assist in minimising the wiring code. Less code is generally good of course.
Post a Comment