But I like my dependencies!
Recently I've been talking about dependency injection and ASP.NET MVC. Each are interesting technologies and are "hot topics" in the ASP.NET world right now. I had decided that my newest project would utilize these, if for nothing else but to learn them in more detail.
I had spent a few days working on the service level code for this project. After building a few dozen interfaces and concrete classes, I felt like I simply had too much unnecessary code. In my situation, which is equivalent to 95% of my past projects, the benefits of dependency injection did not outweigh the tediousness of implementing it. I'm not going to reuse any of the code in my data, business, entity, or services layers. So why spend so much effort and add so much complexity to decouple them? I don't need extra implementations of my interfaces that would effectively be injected into my application. So why implement a framework that is so heavily in favor of that?
The only benefit in my situation was in the unit testing arena. In this case, I really had no plans to unit test this application. I simply don't need it here. Now, I'm sure that's awful and everything should be unit tested, but seriously, it's not always necessary. I know test driven development is the popular thing this year but it's not always advantageous to follow that practice or even unit test to begin with. This application is one of those exceptions. I could explain why but someone will object, so I'll move on. :)
After a few days of sitting on the code I had written and debating my course of action, I decided to pull out the dependency injection and ASP.NET MVC and use plan old Web Forms with a typical n-tier architecture. Everything is tightly-coupled and impossible to unit test from the presentation layer, and I couldn't be happier. :) As a disclaimer, I was only using ASP.NET MVC because of how well dependency injection fits into that programming model. See my previous blog entry for more.
I like dependency injection and I really like the outlook for ASP.NET MVC. What I've learned in the last few weeks is that they have their scenarios where they're more appropriate, and that there are instances where they don't fit. The overhead in creating the code to implement dependency injection is not trivial. Take a hard look at your problem, application, and development environment before deciding which path to take. I have a wonderful application I'd like to tackle that would fit ASP.NET MVC and dependency injection perfectly. It's just not the one I'm working on right now.
