Inversion of Control and Dependency Injection

2008-03-25T21:16:00.024-04:00

MVC has not only brought about a change in how we think about designing and building web applications on the .Net framework but it has also reminded most of us about the Inversion of Control (IoC) and Dependency Injection patterns. While most of us have used these patterns before (without even knowing about it), I think that it is very important to understand what these patterns are, how to use them, and why they are important not only with MVC but in everyday "coding" life.

IoC and DI are defined and described at length in an article written back in 2004 by Martin Fowler named "Inversion of Control Containers and the Dependency Injection pattern" that I highly recommend everyone read. I am not going to go into great details about these patterns but...

IoC means that an object gets other objects that it relies on through an outside source or framework
Dependency Injection means that an object gets other objects that it relies on through it's constructor or set properties

It is safe to say that these are the same but just remember that there is a difference. I have also found that when people or articles have talked about IoC they have been really talking about Dependency Injection. So enough about that... what does it look like?

Let's start with a simple class which relies on a Data Access class (named "MyDataAccess") to connect to some database...

public class MyObject
{
  private MyDataAccess dataAccess;
  public MyObject()
  {
    this.dataAccess = new MyDataAccess();
  }
}

Imagine now that the "MyDataAccess" implements an interface named "IDataAccess" and we change the code to reflect that...

public class MyObject
{
  private IDataAccess dataAccess;
  public MyObject()
  {
    this.dataAccess = (IDataAccess)new MyDataAccess();
  }
}

But now if our example changes one more time... and this time we add yet another class which implements the "IDataAccess" interface, we would have to add more logic or code to determine which concrete class should be created...

public class MyObject
{
  private IDataAccess dataAccess;
  public MyObject()
  {
    int dataAccessType = (int)ConfigurationManager.AppSettings["daType"];
    if (dataAccessType.Equals(1))
    {
      this.dataAccess = (IDataAccess)new MyDataAccess();
    }
    else
    {
      this.dataAccess = (IDataAccess)new YourDataAccess();
    }
  }
}

Clearly this is going to be a problem each time we want add a new class which implements the "IDataAccess" interface. Now expand this out to several classes which depend upon an "IDataAccess" object and you start to see the overhead with maintaining that code.

Enter the Dependency Injection pattern where we pass in an "IDataAccess" object as a parameter to the constructor. This then moves the responsibility (or control) of creating the "IDataAccess" object outside of our class or outside of it's scope.

public class MyObject
{
  private IDataAccess dataAccess;
  public MyObject(IDataAccess dataAccess)
  {
    this.dataAccess = dataAccess;
  }
}

So now any time someone creates an instance of this class they can clearly see that it needs or depends upon an "IDataAccess" object. We have also increased the test-ability of our class by being able to pass in stubs or "mock" objects.

In my next post I will cover more of the benefits and show it works amd how it is used in Testing, MVC and LINQ frameworks.

ASP.Net MVC Source Code Available... our first test

2008-03-21T20:46:00.007-04:00

Scott Guthrie recently posted an article about the ASP.Net MVC Source Code becoming available from the CodePlex website.

I think that this a huge step in the right direction. I would even go as far as saying that this "move" was intentional. If you take a minute and think about what this means... you will see what I am talking about.

With the source code to the MVC library being made available... it is almost like we as developers are being tested. Will we take the source code and make it our own? Will we report back defects and enhancements back to Microsoft to improve this feature? Will we open it up and try to break it and find flaws in the underlying code?

My point being that if we take the right approach as a community and as a team then not only will we (the end users of these features) become more familiar and confident with these bits but our input and feedback will find a larger and more important audience in the long run.

Is that to say that when I (a simple developer in the .Net world) find an issue with the way that they (the developers at Microsoft) implemented some piece of code expect it to be corrected? No. Is that to say that when I feel like there is a feature or method that can make my life easier it will be included in the final release? No.

What it does mean is that I am given a chance to make the community, feature, and the platform as a whole better. Sure... I am only one voice. If my voice is included along with others... it becomes easier to hear. If I am given the chance to work with and validate the feature as a "real world developer" then when the feature or functionality is incorporated... we are the ones to blame if something doesn't do what the rest of developers feel like it should.

All and all... I feel like this is a tremendous opportunity that is being given. While this would not be considered "open source" by any stretch of the imagination, I (little old me... a simple developer) am being given the chance... to change... Microsoft and the .Net language.

Take a minute and think about what that means to you...
Do you want to be a part of the community or simply consume it?

Refactoring... Me

Inversion of Control and Dependency Injection

ASP.Net MVC Source Code Available... our first test