DI or not DI
One of the first assumptions floating around the PRISM team room was the use of an Inversion of Control container to provide dependency injection. At this point in the project, I've fought against making any and all assumptions that increase complexity.
Pros:
This would be a great place to share services between modules. Just register your service by one of its interfaces and other modules just need to add a constructor parameter with that registered interface and the instance of your service gets injected into the object at construction, assuming you use the IoC container to build up the object.
IoC containers can usually resolve cascading dependencies. Let's say your CustomerManager class depends on an ICustomerRepository. There is a NorthWindCustomerRepository that implements ICustomerRepository but it depends on an ILogger. Assuming that the IoC container can resolve ICustomerRepository and ILogger, when someone asks the container for an instance of CustomerManager, it will return a fully functional instance with cascading dependencies fully populated. Upon receiving the CustomerManager instance from the IoC container, you should be ready to rock and roll.
Cons:
Why go to the extreme of using IoC and DI? A factory should be able to new up or provide instances to most anything we need without the complexity of IoC.
I'm trying to tackle this project with an TDD mindset. I want to build into the system only what is necessary to make the unit tests pass. However this is an architectural decision that will impact the project long term. Instead of starting the production code with building a factory and then quickly abandoning it for an IoC container, perhaps the writing is on the wall and I should just start with the IoC container.
If you have a strong opinion on this, one way or the other, please let me know.
