Is Dependency Injection Container needed?

ballistic posted on Wednesday, December 09, 2009

Hello,

I am working on my first MVC project and would like to make every effort to have my project as testable as possible.  I am going through the examples in the latest CLSA 3.8 videos and have a couple of questions.

When using the factory method to determine which DAL to use:

    Since the DalFactory is initializing the appropriate manager (DataAccess.Ado or DataAccess.Mock from the example) base on the value of the "DalManagerType" key in the config file is a "dependency injection container" (like Unity) needed?

Also, the Insert and Update methods in the DataAccess require each property to be passed in as a parameter.  Does it make sense to pass in the actual object (this) to the Insert method and have it read the properties itself? Not really sure what the downside of that would be.  (Similar to the Insert and Update methods for the DataAccess' TestObject in the ObjectFactory demo)

Thank you,

 - Andres

RockfordLhotka replied on Wednesday, December 09, 2009

You can certainly use a DI container if you'd like. I specifically didn't do that in the videos because it is such a huge level of complexity to take on - it would be a video all by itself just to explain the concept, why I chose framework X (instead of Y, Z, A, etc), how the framework works, its good/bad points, etc.

The Repository pattern is so much simpler and doesn't require a framework :)

My implementation choices were designed to minimize the breakdown of layer boundaries and to minimize coupling.

For example, if you pass 'this' to the DAL.Insert() method, then the DAL must know a great deal about the business object - including how to bypass authz/business/validation rule checking (and there's no way to do that from an external object other than an ObjectFactory).

Passing explicit parameter values means the DAL knows nothing about the business object, and the business object really knows little about the DAL - nothing beyond the interface actually - nicely decoupled.

RockfordLhotka replied on Wednesday, December 09, 2009

ballistic:

Hello,

    Since the DalFactory is initializing the appropriate manager (DataAccess.Ado or DataAccess.Mock from the example) base on the value of the "DalManagerType" key in the config file is a "dependency injection container" (like Unity) needed?

You should also consider that DI containers typically drive off config file metadata too. In other words, if you decided to use Unity (or whatever) you'd end up putting a bunch of XML goo in your config file to tell it how to do its job.

One way or another your code needs some dynamic, configurable mapping to something real. The question is which of several well respected design patterns works best for you, by incurring the least complexity, overhead, etc.