(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.
