Inversion of Control \ Container Framework

[sphaso]

The idea of using an IoC Container (e.g. Spring) has been raised. This would help us greately in managing dependencies among classes. I think we need to ask ourselves a few questions:

• Do we really need an IoC Container or would some factories do the trick?
• Which IoC Container should we use (if any)?
• How are we resolving dependencies (different strategies for client and server)

[paddatrapper]

• Do we need an IoC Container: I think eventually we will. Especially as the project grows. So using it from the beginning would make things easier. However I am cautious as I have never worked with an IoC Container before so I'm unsure how to use it properly. This is not much of an issue as I am happy to learn and adapt.
• So far I have found this comparison between PicoContainer, Guice and Spring
• The priority for the clients is easy of distribution as they will be deployed to many machines. I realise there are applications to manage deployment, but simplicity makes things much easier.

My question would be how does this affect the final distribution/package? Would the IoC Container code be required or would it inject dependencies into the code thereby enabling a simple distribution of a jar archive with resources such as images?

[sphaso]

• We can just postpone the adoption of an IoC container and see if we really (really) need it
• I'm undecided. I know that Spring is the supposed "standard" in the Java world but I really despise XML configurators :) I'd like something that allows AOP too, but maybe I'm over-engineering
• It's just another dependency in your POM, it doesn't affect portability so it doesn't really affect distribution\packaging. You just write Bind() instead of countless "new" statements.

[paddatrapper]

Guice is apparently somewhat AOP-like. I agree with the postpone sentiment. We can come back to this once the project has matured a bit