200 Page Manual on Inversion of Control (plus or minus 199)

Thursday, October 08, 2009 -

I’d like to preface this treatise with an appeal to those of lesser intellect – please close your browser now. The concepts you read below are quite high-minded and we have a secret handshake you don’t know. We are “The IoC Community” and we rock the concepts yo.

For those who haven’t read the 200 page manual on IoC – well here ya go. If your little brain can’t handle the complexities of this post might I suggest turning on Howard Stern and Spolsky at the same time, full volume, and holding your breath until you see patterns in the air. This usually helps when wondering WTF Joel is talking about.

Let’s take a walk on the Cool Kid side of the street and see what Inversion of Control is all about…

The Setup: My Blog

So I’m building my blog (more on that later) and it makes for a really good demo since most people understand blogs. So I’ll use it for this discussion. Let’s pretend I have a PostController (using MVC) and this thing shows Posts.

I have a single action called “Index” that grabs data from my database and sends it down to my view (let’s pretend I’m using Linq to SQL):

public ActionResult Index(){
   var db=new Model.DataContext();
   var posts=db.Posts.Where(x=>x.IsPublished);
   return View(posts);
}

Groovy. Now let’s get on with this…

Analysis

What I’ve done here is pretty typical, and what you would see in any demo given at a Microsoft conference. The person writing this code can easily invoke the “This is a demo/small app so shutup” rule when the Cool Kids cry foul – and that would hold most likely as it would be either Hanselman or Scott Gu giving the demo and those guys have swagger like that.

There’s no need for complexity at this point – which is true, however it should be noted that we’ve incurred what’s known as “Technical Debt” – which is akin to repairing a go-kart with duct tape. Like debt, you could live with it, but more than likely it will cause you problems as you build out your app.

The Next Step: Making Sure It Works

Typically what you might do, as a developer, is to hit F5 (Debug/Run) to see if data appears on your page. It’s still magic to me after all these years to see data from my DB hit the screen – I dig that rush and for a moment my little itch is scratched and I feel good about myself. I see data there – so it works.

But then I begin to think – do I really want to hit F5 every time I want to make sure this page runs right? I’ll appease the Cool Kids and add a test:

[Test]
public void Post_Should_Show_Posts(){
   var controller=new PostController();
   var view=controller.Index() as ViewResult();
   var posts=view.ViewData.Model as IEnumerable<Post>;
   Assert.IsGreaterThan(0,posts);
}

What’s this test telling you if you put your programmer’s hat on? The title is a bit misleading as we don’t know what the view will actually “Show” – moreover we’re just testing that we have posts.

This test will fail – immediately – and it will keep failing no matter how much code we write. Why? Because I have no data in my database and this test will fail until I add some. Being the impatient type I add a record to my DB and my test passes.

If your geek senses are tingling – that’s a good thing! This test is pointless to say the least – what “unit of functionality” is it testing? None. And if you look at this a bit longer you’ll start to realize that I’m not chanting or smoking a secret mix of techno-herb and sassy weed – I’m just using common sense and basic coding principles. What happens if I remove all records again? The test fails. Does that mean my Controller won’t show posts? Not at all – and this is one main reason the People Who Like Testing (Cool Kids) advocate against hitting the database.

Well what’s the point of testing Controllers then if it’s this hard!

It’s not hard – it simply requires you to look a bit further and use some tricks – that’s all.

Rewind and Refactor: Using an Interface

Interfaces are scary to many developers at first – they seem rather pointless until you actually use them. In this sense they work perfectly since I don’t want to talk to my database at all – what I really want in my Controller is the ability to get data from *somewhere* (not necessarily a SQL Database). That’s the important part – and yes it’s an abstraction – but that’s one step towards the idea of “Loose Coupling”.

When I wrote my initial Controller Action above (Index), I planted data access code right in it from Linq to Sql. In doing that I also made a decision that was explicit: whenever I use this controller, I also need to make sure I have my Linq to Sql classes set up and pointed to my Post database. This is called “coupling” and you can think of Linq To Sql and your PostController on a date, having babies if that helps.

Let’s pretend I made an interface (IPostRepository) with a single method called “GetPosts()” which returns an IEnumerable<Post>. Now I can use it instead of Linq:

IPostRepository repo;
public ActionResult Index(){
   var posts=repo.GetPosts();
   return View(posts);
}

This is a good first step – but how does it help me? I can’t instantiate an interface can I? So how the heck to I make this work?

Next Step: Dependency Injection

Put in plain English: our PostController has a dependency on data from the IPostRepository – it needs it to function (which is a dependency sort of like your college roommate needed to wake-n-bake in order to get moving).

We could just implement our interface in a concrete class (let’s call it SQLPostRepository since we’re using SQL Server) somewhere and instantiate that:

IPostRepository repo;
public ActionResult Index(){
   repo=new SQLPostRepository();
   var posts=repo.GetPosts();
   return View(posts);
}

Now the code works, but we’ve traded one dependency for another (on SQLPostRepository) – what did we gain here? Well nothing actually – and the Cool Kids are getting pissed.

What we should do is to allow the calling code to specify this dependency when creating the class, defaulting to the SQLPostRepository if nothing was set:

IPostRepository repo;
//injectable constructor
public PostController(IPostRepository postRepository){
   repo=postRepository;
}

//default
public PostController(){
   repo=new SQLPostRepository();
}

public ActionResult Index(){
   var posts=repo.GetPosts();
   return View(posts);
}

This works, and now we can test this by sending in a fake repository (made up of in-memory lists) or we can use mocking, which basically “lies” about stuff. I’m going to sidestep the testing aspect here (easily will derail the post) as I want to stay on Dependency Injection and Inversion of Control.

Analysis.

On the face of it we’ve “loosened things up” which is always good as now we can plug in SubSonic instead of Linq to Sql if we wanted to, or next year we can use the [Groovy New ORM] that’s all the rage.

There is a problem, however, with “Naked Dependency Injection”, and that problem is that Controllers typically have more than one dependency. There might be logging involved, email, a comment repository, user repository, etc and you’d have to inject each of these (and update all the calling code when you change stuff).

It’s pretty easy to end up with “Constructors Gone Wild” by following this pattern, and on occasion you can end up with recursive construction – which is really ugly and a maintenance nightmare.

The Answer: Inversion of Control

It’s a strange name – Inversion of Control – it sounds like you’re turning your app inside out. Here’s what it means:

Normally, when your class needs to use another class to do something it will instantiate an instance of that class, use it, and then discard it at some point. In this case our PostController class is controlling the instance of the IPostRepository – determining when it gets created and how. All these decisions being made for our IPostRepository – isn’t that just a bit presumptuous!

Inversion of Control does the exact opposite. You have a thing called a “Container” that instantiates the classes and controls their lifetime (according to some rules you set) and it hands them out when asked for. In our blog app the control is removed entirely from the PostController and is “inverted” – handed completely to the container which tells your PostController “this is the object you’re going to get  and you’re going to like it”.

The IoC container is essentially a big playground of objects just waiting to be used and reused. As you can imagine, there’s a lot of freedom when your objects are cut free like this – you can setup all kinds of rules for them and even control their lifetime. Want to make one a singleton (yuck)? You can do this easily with a half-line of code. Want to set an object’s lifetime to that of the request? Same thing.

I’ve used StructureMap a lot as it’s what I know – but Ninject or any other framework is pretty easy to pick up, no Big Brain required – so that’s what I’ll show you below.

The first thing you do is to tell StructureMap what type of class you want when a given interface is used in a constructor. You do this in a thing called a “Registry”:

    public class BlogRegistry : Registry {
        protected override void configure() {
            
            ForRequestedType<IPostRepository>()
                .TheDefaultIsConcreteType<SQLPostRepository>();
           
        }
    }

Then, in your Application_Start you call it:

protected void Application_Start()
{
    StructureMapConfiguration.AddRegistry(new BlogRegistry());
}

Now when you want to use it, you ask StructureMap for an instance of the object:

var repo=ObjectFactory.GetInstance<IPostRepository>();

On the face of it this might seem like a lot of code for nothing – and it’s a bit true. IoC is an investment in your application – not a direct deposit. What you gain is the ability to “unhinge” your classes from one another, reusing them in other applications as needed.

Most importantly, as you’ll see below, I’ve lost all of my “technical debt” and not many things are more fun than being debt-free.

In the case of my blog application, I can override my ControllerFactory and ask StructureMap to build my Controllers for me – this reduces my examples above to this:

IPostRepository repo;

public PostController(IPostRepository postRepository){
   repo=postRepository;
}

public ActionResult Index(){
   var posts=repo.GetPosts();
   return View(posts);
}

Now the Controller knows nothing of any implementation – which is awesome.

Summary

If you’d like to know more about DI/IoC (and some details on how to hook it up to an MVC App), I did a full hour’s video cast with Jeremy Miller (creator of Structure Map) and you can watch it here: http://www.asp.net/learn/mvc-videos/video-366.aspx. It’s about an hour long and I think the best of the entire MVC Storefront series.

It took me just over an hour to write this post – how long did it take you to read it? Does IoC make more sense to you? Regardless if you think it’s worth it (you might think it’s crap) – is it too high-minded? Too complex?

IoC containers take a simple, elegant, and useful concept, and make it something you have to study for two days with a 200-page manual. I personally am perplexed at how the IoC community took a beautiful, elegant article by Martin Fowler and turned it into a bunch of complex frameworks typically with 200-300 page manuals.

Am I a whole lot smarter than you?

I think that people who use IoC containers are (A) very smart and (B) lacking in empathy for people who aren't as smart as they are. Everything makes perfect sense to them, so they have trouble understanding that many ordinary programmers will find the concepts confusing. It's the curse of knowledge. The people who understand IoC containers have trouble believing that there are people who don't understand it.

Is it harder to read my final PostController versus my “Naked DI” Controller above?

I believe that if you use IoC containers, your code becomes, frankly, a lot harder to read. The number of places you have to look at to figure out what the code is trying to do goes up by at least one. And somewhere in heaven an angel cries out.

I mentioned in my last post, in the comments, that I’m no stranger to disagreeing with Joel. It crosses the line, however, when he advocates idiocy – the notion that *you* are too dumb to figure this stuff out.

Are you?