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.

Comments (2)
  1. PLindes says:

    Our experience is that the factory approach is a good idea.  We’ve been working a lot lately on getting code coverage for unit tests of the pieces of our MVP triads.  Having factories that produce either real or mock versions of each component seems to work much better than trying to use CAB’s DI structure.

    Peter Lindes

  2. A while back, I was Dev Lead on the Smart Client Software Factory (SCSF) when we added the ability to

Comments are closed.

Skip to main content