Reasons to use Unity

Oct 20, 2009 at 1:32 PM

Hi all,

I'm sure this is a very silly question. But I'm a newbie to this. Request you to bear with me. It's sure there must be some great benefits of using Unity in applications. Can anyone please help me understand the benifits. I went through the Hands on lab 4.1. I understood a little bit but not everything. 


Thanks in advance

Oct 20, 2009 at 8:30 PM
Edited Oct 20, 2009 at 8:33 PM

I am guessing that your question is not only asking for reasons to use Unity but for reasons to use any DI framework.
All the major DI frameworks will essentially allow you the same benefit which is loose / configurable coupling between application modules. 

So the idea is that you want higher level modules to be able to configure lower level modules. The lower level modules have no idea that the higher level modules even exist, so how can you configure it for a module that it has no knowledge of? The answer is in the container model that DI frameworks provide you with. So there is a common “container” where you can register types to be instantiated. Then all modules can go to this common container to retrieve the desired(configured)  type. 

Let’s say I have a lower level data access module that  I will build off of to make an application. I want this module to be able to instantiate a data access object based on the type of data store needed in the application I am building.  So instead of hard coding the type of data access object to instantiate, I can instantiate the data access object by retrieving it through the container. Then my higher level module that I am building can configure the container to return the type of data access object I need. 

For this all to work you need to build your types based on abstractions, so you can then make different implementations of those abstractions and in your code work with the abstract types only. Also, in order to wire up all the modules you need to be able to have global way to get at the container, so using a Service Locator of some sort will be essential.

Oct 27, 2009 at 7:28 AM

Thanks a lot jodomofo. It makes at least some sense to me. 

Like in your example data access module has some functionality to access and manipulate a particular database. Say it SqlServer. But while implimenting funtionality you will never refer SqlServerDataAccess class. Instead you will use IDataAccess interface. Now if the higher level module want to use the same functionality of data access and manipulation but for some other database. Say it MySql. So it can then create concrete implimentation for MySqlDataAccess using IDataAccess interface and use it in higher level module by configuring data access module in the way so that it uses MySqlDataAccess class.

Please correct if my understanding is wrong.

Thanks very much.


Oct 27, 2009 at 6:00 PM

Yes, you got it right.

Keep in mind the scenerio we are talking about here is only using one aspect of the DI framework; dynamically resolving types based on configuration.

The other important part of DI is the acutual Dependency Injections, where you are not only resolving the requested type by also resolving any dependent types and injecting them in when instantiating your requested type.

Even just using the container to resolve types with no injection, is highly useful.



Oct 29, 2009 at 6:24 AM
OK. I will keep in mind. Thank you jodomo very much. :)

Best regards,