Dhanji Prasanna

+ Follow
since Aug 30, 2009
Merit badge: grant badges
Google Wave core engineer.
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dhanji Prasanna

I spend several chapters on this subject =)

But the short of it is: prefer Constructor DI almost always, except when you have a circular reference to resolve.
Hi Stanislav,

It helps by moving all the weight of the factory work into a library framework. I recommend watching this video:

Or reading this green paper pdf:

Here is a comparison from the Guice wiki:

In performance, a speed test we wrote outdid spring 1.0 by 100x and spring 2.5 by 10x (This benchmark is available in the Guice code repository). Both continue to make speed improvements.
I hope you mean Struts2 and not Struts (avoid the latter at all costs!)

As James says, it is important to learn the principles behind DI and they will help you later in your career. However splitting your attention between too many things as you are just starting out may not be ideal. Perhaps learn about it, but decide whether you need to apply it at a later stage.
Hi Vladimir,

DI and testing are very closely related concepts. DI facilitates testing and is thus a natural fit with the TDD paradigm. I explore testing in quite a lot of depth in my book. Check out the green paper pdf (free download) on the book's site to get a preview of some of the testing content:
Yes, absolutely!

In fact you can use many of the design patterns I describe in my book with hardly any changes. Spring has a .NET edition and there is an equivalent of Guice in C# called Ninject.
I try to describe working with legacy code in many places. Particularly how to attack configuring your injector to work with sealed code used in new code. However, if you are looking for refactoring specifics (for example, refactoring patterns) that is probably outside the scope of DI.
Hi, I would suggest that is specific to what kind of application you are building. You should check out the green paper linked above as a good introductory bit of reading.

There are many nuanced interpretations of the differences between them. As I said in my linked post above, I try to avoid IoC altogether as it tends to apply too broadly, and stick instead to DI which everyone is rather clear on (or hopefully can be convinced so!)


Thanks for your question it is quite interesting. Actually I don't see that as a limitation. An object obtained from JNDI and serialized on the wire will still have the same problem you describe.

The correct solution is of course to *always* obtain the object via JNDI. However, this means you have to go through some contortions to serialize services. With the injector this is solved by using what we call "Static" injection in Guice. When an object is brought out thru the wire you can statically repopulate it with deps during deserialization.

This pattern is discussed in some detail in the Guice forums, but essentially it is not a limitation of DI as such. And more a problem about transmission across the wire. In general, I would not send services across the wire anyway, but separate their state into value objects which are easier to transmit and do not hold references to instances in a particular VM.

Hope that helped!

Hi Jess,

Yea that is a common question. The green paper pdf compares and explored the differences between the service locator model and DI:

As for DI support, if you mean JNDI support then both Spring and Guice do this out of the box.
The examples are generally in Spring and Guice. Sometimes introducing other frameworks where they excel (for example, PicoContainer). As for the comparison I believe you have seen my answer elsewhere on this forum =)
Certainly not big-bang.

Yes I have introduced it in a couple of applications from the ground up. The key is to start with the parts of code that are changing the most, then work your way outward. That way your immediate pain is eased a bit, and everyone on the team is using DI regularly and gets comfortable with it.

There are lots of compelling reasons in the political fight, you essentially have the good ones though: modularity, testability, loose coupling and reduction of error-prone boilerplate code.