Trying to grasp the idea of DI/Unity and possibly apply it to our simple application

Question

Our app basically is a few forms that are filled out by people.. Then these forms are validated and reviewed and reports are created..

So I was thinking about DI and messing with a simple example of Unity + MVC

http://netmvc.blogspot.com/2012/04/dependency-injection-in-aspnet-mvc-4.html

So could it be useful for something or overkill ? It seems to me the idea behind DI is to dynamically grab objects of a different type.. So in my case maybe those can be a set of rules for validation of a form... Something like SyntaxRules1.dll, BusinessRules1.dll, CalculationRules1.dll... So then as time goes by maybe additional sets of rules would be created so I can drop another DLL like BusinessRules2.dll in a folder and DI would pick it up in the boot strapper..

But then again if it changes very little then using DI might be pointless and just be a layer of abstraction that is not needed..

Do I have the right idea? Is there any other ideas how DI could be useful for this type of app ? Could I make the entire view/controller/model or each form its own DLL ? That make sense ?

I just read alot of theory and struggling to find some concrete examples of what DI can do.

Answer 1

It seems to me the idea behind DI is to dynamically grab objects of a different type

No, it isn't. DI stands for Dependency Injection. The idea is that instead of classes instantiating the classes/services that they need in order to operate, these are passed in to them (i.e. injected) - this is normally done either on the constructor or through public properties.

Writing classes in such a way allows you do have a more modular structure to your code and means that the user of a class (the calling code) needs to pass in the dependencies.

This concept is that of Inversion of Control (IoC), which uses DI to achieve this goal.

Where an IoC container like Unity comes into play is that it allows you to determine in configuration (which can be strongly typed fluent code configuration) how to provide a class with its dependencies.

---

Now, I would argue that DI is a useful technique in any application. It allows you to write more testable code and allows you to test your code in isolation (meaning without having to draw in the dependencies). Mocking frameworks help in this respect.

An IoC container, on the other hand, is probably overkill for a small and simple application. It is handy in cases where you have chains of dependencies or many dependencies in the codebase.

---

The example you have given - picking up rules dynamically sounds like something that would be better achieved using a plugin architecture, possibly using MEF. It is not something directly related to DI or IoC.

Answer 2

I have done what you're talking about using Unity with a slight change in your perception of Dependency Injection (DI). All dependency injection means is that you pass in an instantiated class type into your class's constructor rather than having your class instantiate that type.

As one previous poster stated, this is good for testing purposes as you can write test code for your class and pass in different instantiated types to test your class functionality.

However, to do what you're asking in regards of passing in BLL, you would use DI but instead of passing in your BLL class, you would pass in a service/controller object that would return an appropriate BLL. That service object would internally know which BLL to return based on functionality that you created. That service object could be an Interface type with a function like getBLL(myCustomerNumber);

The dynamic part comes in as Inversion of Control (IOC). So, in terms of IOC, you would register your service (the class that knows which BLL to return) to that interface type. Therefore, every time that service is referenced in a class constructor, unity would use the service (class) that was registered to pass into the constructor.

Please take note: With unity, you can register/create a class/service with/without a life time manager. This is important to research because if you don't have a LifeTimeManager, the registered class will be created every time it is referenced. With a LifeTimeManager, it will be created once in the system and used throughout the system. You may want this in certain circumstances and others you may not.