Dependency injection, providers and ASP.NET MVC
I've been thinking a lot about all of the frameworks we have now to use with our, uh, frameworks. There's a framework to solve every problem. Dependency injection frameworks are of particular interest to a lot of people because they make unit testing ridiculously easy. They're also well suited to something like ASP.NET MVC, where you're trying to make as few dependencies as possible between the various concerns.
But I was chatting with someone the other day about all of the frameworks for DI, and he expressed concern that he wasn't comfortable depending on a lot of external libraries for some things. His view (pun intended) was that you start to junk up a relatively simple framework like MVC by putting all kinds of other stuff into it to support another framework, and that introduces different kinds of risks. For example...
- You're decorating everything with attributes.
- There are all kinds of configuration files or classes to do the hookup.
- You'll replace the standard controller factories, perhaps giving new devs one more thing to learn about for your project.
- Global.asax becomes even more of a dumping ground (more because of the placement of routing there plus DI framework init).
- It just feels dirty to some to be using another library you don't own.
I think these are all valid concerns, though the scope of them depends a lot on your specific scenario. The funny thing about using frameworks that are named after design patterns is that everything becomes an academic debate about where and how you do this and that. And if you're a junior developer wanting to impress your peers, or a senior developer not wanting to set a precedent for the "wrong" thing, you want to get it "right."
Many of the examples published on the Web and in books suggest simply using different constructors on MVC controllers to handle DI in a rational way that doesn't require an additional framework. That allows you to keep the default controller factory and let your unit tests instantiate them with your mock objects. I read a lengthy discussion forum thread that suggested this wasn't proper either because you aren't testing the way that the objects are created in the real production environment. I thought that was a pretty thin argument, but I do see the point.
I got to thinking about how the provider model introduced in ASP.NET 2.0 worked pretty well for a lot of things, and it was used effectively before that in wiring up swappable data access layers on various apps. Creating a lightweight container to do that wire-up would be pretty straight forward, even if it did reinvent some wheels.
I don't really have a point that I'm after here. I guess these are things I'd like to hear people talk more about. What are you doing in the real world to keep things testable and maintainable?