This goes double for applications built on SOLID principles, especially the Single Responsibility Principle and Dependency Inversion Principle.  These types of applications tend to have many small classes that do one thing and that are isolated from the code in other classes.  It’s very possible for one class to return results and another class determine whether those results are necessary.  It’s also possible for a class to have a dependency on another class that is expensive to instantiate.  Without an idea like lazy-loading, these situations could force you to couple bits of code that would normally be kept apart.

I was in one of these situations recently in an ASP.Net MVC application with MVC Turbine.  I had a route with a route constraint that had a dependency on a repository.  If a specific part of the URL matched an item in the repository, the route was considered valid.  The issue I had was that the routes were being built before my caching “blade” was run, so the route constraint was instantiated with a repository tied to my database instead of a repository tied to the cache.  What should I do?  Bring in my IoC container as a dependency to the route constraint?  Should I alter MVC Turbine to make my caching blade to run before the routing blade?  Should I write a special lazy loader for this situation?

In every time I’ve been in this situation, I’ve gone with the last option.  It’s pretty easy:

public class RepositoryLazyLoader {

   private IServiceLocator locator;

   public RepositoryLazyLoader(IServiceLocator locator){
      this.locator = locator;
   }

   public IRepository GetRepository() {
      return locator.Resolve<IRepository>();
   }

}

This lazy loader is basically a wrapper around my IoC container.  It seems like I’ve had to write one or two of these in every project, so I had an idea:  Why not write this one more time and never write it again?

MvcTurbine.Laziness

Since I use MVC Turbine on every ASP.Net MVC application I write, I decided to write a “blade” (which is essentially a module you can plug into your MVC app) that would handle creating lazy loaders.  Instead of writing a lazy loader when I need one, I can just instantiate an ILazy<T> from my IoC container.  The ILazy<T> has one property, Value, that will return the value from the IoC container.  The value will *not* be instantiated until then, so I can change a constructor like this:

public SuperConstraint(IRepository repository) { // IRepository will be instantiated right NOW

to:

public SuperConstraint(ILazy<IRepository> lazyRepository) { // IRepository will be instantiated LATER

In order to use this, here’s what you have to do:

1.) Use MVC Turbine.
1.) Add a reference to MvcTurbine.Laziness.dll .
2.) Add a reference to MvcTurbine.Laziness.X.dll, where X is either Unity, StructureMap, Ninject, or Windsor.

That’s all. Just by adding references to these dlls, MVC Turbine will suck them into the application startup and add a registration for ILazy<> to your IoC. The only work I’ve done is to figure out how to register ILazy<> into each of those containers (which can be seen here for Unity,StructureMap, Ninject, or Windsor).  Not much there.

Leveraging a CSL

MVC Turbine comes with a common service locator that serves as an abstraction on top of all of the IoC containers.  It’s similar to the Common Service Locator you can find on Codeplex, except that MVC Turbine adds the ability to register mappings as well as resolve them.  If you stick with the standard features that MVC Turbine’s service provider offers, you can actually swap your IoC container without any impact on your MVC application.  Let me repeat that:  You can swap your IoC container without any impact on your MVC application. So with one line of code, you can swap Unity with StructureMap, or StructureMap with Unity, or with Ninject, or with Castle Windsor.  Wow, right?

“Big deal,” you say?  You know how to use your IoC-container-of-choice and you’ll never want to switch?  That’s how I felt a while ago.  I cut my DI teeth on Unity.  I know it.  I know how to handle configuration, lifetime management, interception, or anything else I could imagine wanting out of an IoC container.  All of my projects had direct references to Unity, everything worked, and I thought I was cool.  Then I hit an issue or two with Unity, including a memory leak in the disposal of child containers.  The issues were all worked out in time, but when I was in the middle of them it was pretty scary.  I wrote a huge application that was glued to my IoC container, to the point where I was literally stuck with it.  What if the issues couldn’t get worked out?  What if I *had* to replace Unity?  I could do it, but it definitely wouldn’t be a one-line change.

“But Unity is stinky and my IoC container issue works just fine, I’ll never have to swap it out.”  That’s great, but I think it’s still a bad practice to tie any third-party library directly into your application.  Your classes should depend on abstractions, not implementations, and this is true even with the class that’s responsible for mapping your abstractions to your implementations.  I’ve found, through much experience and pain, that when you tie yourself to anybody else, you’ll go down with them.  Adding one simple layer of abstraction will protect you and will keep your code focused on what you want instead of what they give you.  That’s what a CSL like the that comes with MVC Turbine will provide you.

Think about it this way:  I wanted to provide this ILazy<T> feature in my application.  If I were touching my IoC container directly, this is the point where I’d sink even deeper into it.  I’d write code that could only work with my IoC container, making yet another dependency on a third-party.  The next feature I write will probably be the same, as will the next.  I’m definitely on the wrong path.  But if I write a solution that’s meant to be IoC-agnostic, I’m covered and I’m on the right path.

If you want a better example of this, look at the MVC Turbine framework itself.  It lets you inject IoC into your ASP.NET MVC and MVC2 app, yet it doesn’t tie you to a specific IoC container.  This makes it possible to add this ILazy<T> feature, a Fluent Validation plugin, or any number of things (I’m working on some new ideas) that couldn’t be done if MVC Turbine picked one IoC container.

One Final Point

I know that bringing in an ILazy<T> as a dependency might be the wrong place to implement the “laziness.”  However, sometimes we’re put in less-than-ideal situations (like this routing example), and in those places I want to go with the simplest, testable solution.  I’ll strongly recommend that you NOT throw ILazy<T> dependencies all over your application.

Get MvcTurbine.Laziness here.

public class LoginInputModelValidator : AbstractValidator<LoginInputModel>{
   public LoginInputModelValidator() {
      RuleFor(x=>x.Email).NotEmpty();
      RuleFor(x=>x.Password).NotEmpty();
   }
}

That’s all there is to validating a login form, at least to the point to making sure the email and password were both entered.  See how easy that is?  But the thing is… how do you use it with ASP.NET MVC2?  How do you make its use seamless with the framework?

Well, like most, I started with Jeremy Skinner’s post on MVC2 integration.  He explains how to create your own IValidatorFactory and what code to enter in your global.asax file.  Great help, but couldn’t it be easier?  Do I really want to copy bits of code here and there in each MVC project?  What if I switch IoC containers?  It works, but it didn’t feel like a complete solution to me.

So… I put it on myself to come up with the solution I wanted.  I’m also a big fan of MVC Turbine, a project that integrates IoC throughout your MVC application (which is essential).  MVC Turbine offers the concept of a “blade” that lets you inject code into the startup and the setup of your favorite IoC container.  Essentially, it gives you one place to inject functionality that can then be used throughout your application.  Functionality like… implementing Fluent Validation into your MVC application!

MvcTurbine.FluentValidation

My solution is MvcTurbine.FluentValidation, and the source and binary can be found at here on GitHub.  In order to use it to automatically validate your MVC app, you’ll need to do the following:

1.)  Setup your ASP.NET MVC application to use MVC Turbine (which you should do anyway).

2.)  Add a reference to MvcTurbine.FluentValidation.dll.

That’s it.  Really, that’s it.  By adding MvcTurbine.FluentValidation.dll to your application. MVC Turbine will add the FluentValidationBlade to your application startup.  That blade will scan your project for validators, create an implementation of the IValidatorFactory using your preferred IoC container, create an model validator provider, and incorporate everything into the application.  And to top it all off, it will instantiate your validators through your IoC container, giving you the ability to add dependencies like this:

public class LoginInputModelValidator : AbstractValidator{
   public LoginInputModelValidator(IMembershipService membershipService) {
      RuleFor(x=>x.Email).NotEmpty();
      RuleFor(x=>x.Password).NotEmpty();
      RuleFor(x=>x.Email).CheckThatThisIsAValidEmail(membershipService);
      RuleFor(x=>x.Password).CheckThatThisIsAValidPassword(membershipService);
   }
}

The blade and Turbine does everything for you, leaving you to just use it.  If I added MvcTurbine.FluentValidation to my project, simply having that validator somewhere in my project is all it takes to integrate it with an action that needs it, like this:

[HttpPost]
public ActionResult Index(LoginInputModel inputModel)
{
   if (ModelState.IsValid == false)
      return View("Index");
   membershipService.LogInAsUser(inputModel.Email, inputModel.Password);
   return RedirectToTheHomePage();
}

My validator will have run before the Index action was invoked, and ModelState will be loaded with any errors from the validator.  The validator even checked the email & password combination, keeping my controller clean.  Easy as pie.

The Bigger Picture

If you look at the code to this library, you’ll see a grand total of three classes.  There’s not much there.  I’m leveraging what Fluent Validation, MVC Turbine, ASP.NET MVC, and the many .Net IoC containers  already offer.  I think there is something special here, though, and it’s MVC Turbine’s role as the glue holding them all together.  By hooking into the ASP.NET MVC Pipeline at the appropriate places and abstracting away the registering and resolving of classes from the IoC container, it makes these types of integrations possible.  I’ve written a few of these integrations, and I can tell you — they all, pretty much, turn out like this.  You just get what you need into the right spots, and then you move on.

It deserves more discussion than I can give now, but that’s a more important point than this particular solution.  If you have integrations in MVC where you find yourself having to edit things in multiple places, or if you find yourself continually running to global.asax everytime you want to change something, you need to give MVC Turbine a look.

Download MvcTurbine.FluentValidation here.