Guice is Google’s open source dependency injection framework for Java development. It enables better testing and modularity by taking away the pain of writing your own factories. This article offers a tour of the most important Guice concepts that will leave you ready to Guice up your applications.
Interesting, after trying Unity in .NET I must say dependency injection is a must for extensible apps.
Unity isn’t all that great either. Try ninject, castle windsor, or structuremap if you want to really get into IoC on .net.
It seems like yet another IoC framework without anything to differentiate it from all the other choices
Although I salute most of Google’s project(s) as great initiatives… I must say that another IoC framework seems a bit redundant considering that Spring is already mature and fully integrated in thousands of applications around the world.
What’s next? A .NET replacement named .google?
Guice is not new. it has been almost two years it is out. Spring made a lot of catching up after Guice was released. it has advantages (speed, configuration, compile time safety etc.) over Spring. Spring is bloated. But if you are looking for a tiny IOC library, butterfly ( http://butterfly.jenkov.com/ ) is a good choice too.
Edited 2008-12-12 09:27 UTC
Spring has indeed been around a long time and is very powerful. However, Guice beats it hands down for a simpler design. For smaller projects Guice is less work to use. With Hibernate you have to understand the tags in their XML dialect and use them to wire stuff together, with Guice you need to know a lot less to be productive (which is why I think Guice has the superior ‘design’).
While dependency injection and Inversion-of-Control has it’s place I think it is *massively* overused in almost all of the of the recent (commercial) projects I’ve had to maintain/extend.
Rather than using these frameworks for resource acquisition they also get used to configure and assign all sorts of objects on to each other. Spring in particular gets used to wire stuff up all over the place and it makes it very hard to figure what is constructed when and where (particularly on large modular projects where there can be many Spring contexts about).
This model is crap for maintaining a large project so I have come to conclude that less IoC should be used (but not zero) in projects in favour of more parameter passing and regular property assignment. Otherwise you have a lot of “WTF! where did that come from?” moments when maintaining the code written by others.
So, be careful when using IoC, ok?
Its sort of how the first system you design after reading the GoF book is GUARENTEED to be over engineered.
I can’t imagine life without IoC at this point, but just like design patterns and database normalization, ivory tower theory needs to be balanced by a good dose of real world experience and common sense.