Dependency Injection was made for ASP.NET MVC

It's not that you can't use dependency injection in any .NET application, because you can.  It's just that dependency injection fits so well in the ASP.NET MVC programming model.  While building up a simple example for how my new application would be architecturally designed, I found using dependency injection with Web Forms as troublesome as trying to fit a square peg into a round hole.  After some modifications and adjustments, I could get it to work, but it just didn't feel like a solid fit and certainly didn't make me any more productive.

I decided to give the ASP.NET MVC programming model a try and found the experience much smoother.  Not only did everything simply work easier, but you get a sense that the two were meant to be used together.  Using the Controller approach found in MVC, it's extremely easy to inject your dependencies using constructor injection.

Designing software while using dependency injection has changed my normal approach.  I've found myself creating an extra layer or two of abstractions.  The implementation of the classes I'm building is pretty simple and somewhat resembles the Facade pattern.  My classes essentially boil down to a small set of service classes that are injected into the Controllers as needed.  All of the services that are injected into the Controllers are done so by using interfaces for the service.  The concrete implementation of the service classes are actually composite classes.  They use the various repository classes (think subsystem) they need to offer up a set of common methods that define the service.  I guess it sounds more complicated than it really is, but the idea is that everything is loosely coupled to everything else.  Everything is interface driven, so supplying concrete implementations is the job of StructureMap, my dependency injection framework of choice.

I can't say that dependency injection is "the way to go" for every scenario.  In fact, my current application doesn't really need it except for maybe one instance.  However, what I do like about using dependency injection is the side effect I mentioned above.  Using it has me thinking about my n-tier architecture in a different way than before.  I've found useful instances of working in an interface driven environment.  I also enjoy the approach of creating services for the various subsystems in my framework.  It's certainly something you can do without dependency injection and ASP.NET MVC, but it's something I've found very useful in solving business problems while using those technologies.

kick it on DotNetKicks.com

5 Comments

  • What do you think of StructureMap vs. other DI frameworks? Have you looked into anything else?

  • I can't really speak to any other framework. I barely got in to Spring.NET. Only enough to see I didn't really get it. I had a basic sample working in Spring.NET that used an XML configuration file. I believe you can have an XML-less configuration with Spring.NET too. I just didn't take it there. I found many more samples and usages of StructureMap.

  • Do you think dependency injection is a good discipline for any project (due to benefits in changing how you approach your code), or do you think it's overkill for small projects?

    Great read btw, just building my first MVC site and trying to decide on whether to adopt DI.

  • When I first began wrapping my head around dependency injection, I thought it was overkill for smaller projects. However, with a better understand of it and its benefits, I feel that you should always use dependency injection. With my design style, it fits perfectly in my projects, regardless of size.

    I recently blogged about this here: http://www.compiledmonkey.com/2008/10/06/you-should-be-using-dependency-injection/

  • Dependency injection was made for asp net mvc.. May I repost it? :)

Comments have been disabled for this content.