(Repost from my personal blog.)
This is another post in a series about rebuilding one of my Web sites, which has been around for 12 years. I hope
to relaunch soon. More:
Part I: Evolution, and death
to WCF
Part II: Hot data objects
Part III: The architecture using the "Web stack of love"
If anything generally good for the craft has come out of the rise of ASP.NET MVC, it's that people are more likely
to use dependency injection, and loosely couple the pieces parts of their applications. A lot of the emphasis on coding this way has been
to facilitate unit testing, and that's awesome. Unit testing makes me feel a lot less like a hack, and a lot more confident in what I'm doing.
Dependency injection is pretty straight forward. It says, "Given an instance of this class, I need instances of other classes, defined not by their concrete implementations, but their interfaces." Probably the first place a developer exercises this in when having a class talk
to some kind of data repository. For a very simple example, pretend the FooService has
to get some Foo. It looks like this:
public class FooService
{
public FooService(IFooRepository fooRepo)
{
_fooRepo = fooRepo;
}
private readonly IFooRepository _fooRepo;
public Foo GetMeFoo()
{
return _fooRepo.FooFromDatabase();
}
}
When we need the FooService, we
ask the dependency container
to get it for us. It says, "You'll need an IFooRepository in that, so let me see what that's mapped
to, and put it in there for you."
Why is this good for you? It's good because your FooService doesn't know or care about
how you get some foo. You can stub out what the methods and properties on a fake IFooRepository might return, and test just the FooService.
I don't want
to get too far into unit testing, but it's the most commonly cited reason
to use DI containers in MVC. What I wanted
to mention is
how there's another benefit in a project like mine, where I have
to glue together a bunch of stuff. For example, when I have someone sign up for a new account on CoasterBuzz, I'm actually using POP Forums' new account mailer, which composes a bunch of text that includes a link
to verify your account. The thing is, I want
to use custom text and some other logic that's specific
to CoasterBuzz.
To accomplish this, I make a new class that inherits from the forum's NewAccountMailer, and override some stuff. Easy enough. Then I use Ninject, the DI container I'm using,
to unbind the forum's implementation, and substitute my own. Ninject uses something called a NinjectModule
to bind interfaces
to concrete implementations. The forum has its own module, and then the CoasterBuzz module is loaded second. The CB module has two lines of code
to swap out the mailer implementation:
Unbind<PopForums.Email.INewAccountMailer>();
Bind<PopForums.Email.INewAccountMailer>().To<CbNewAccountMailer>();
Piece of cake! Now, when code asks the DI container for an INewAccountMailer, it gets my custom implementation instead.
This is a lot easier
to deal with than some of the alternatives. I could do some copy-paste, but then I'm not using well-tested code from the forum. I could write stuff from scratch, but then I'm throwing away a bunch of logic I've already written (in this case, stuff around e-mail, e-mail settings, mail delivery failures).
There are other places where the DI container comes in handy. For example, CoasterBuzz does a number of custom things with user profiles, and special content for paid members. It uses the forum as the core piece
to managing users, so I can
ask the container
to get me instances of classes that do user lookups, for example, and have zero care about
how the forum handles database calls, configuration, etc. What a great world
to live in, compared
to ten years ago.
Sure, the primary interest in DI is around the "separation of concerns" and facilitating unit testing, but as your library grows and you use more open source, it starts
to be the glue that pulls everything together.
