Planet ASP.NET MVC

Why? Because since at least Visual Studio 2005, the default for tabs/spaces has been: Insert spaces, not “Keep tabs”. If tabs were supposed to win, they would have won the default settings battle. If the default settings in Visual Studio … Continue reading →

My dislike of Flash has been well documented, so last month I thought I would try to see what the internet was like without Flash installed, whatsoever. I removed Flash completely from my system, including any Chrome plugin (Chrome has … Continue reading →

In light of recent conversations around ActiveRecord and Rails, I thought it might be important to recognize the factors in a project success, in terms of the code produced: In order for a software project to be successful, two things … Continue reading →

Flash has crashed for the (hopefully) last time. I’m going to run a little experiment. I’m uninstalling Flash and see how much it affects browsing experience for say, one month. I suspect that most experiences will be fine on Chrome, … Continue reading →

Certain arguments seem to resurface every few years, like whether or not to use a mocking framework, and more recently on Twitter on why .NET still uses Hungarian notation in a few select cases, namely: Interfaces Generic type parameter names … Continue reading →

I had a great chuckle in this article linked from Daring Fireball about 10 reasons why the Droid Bionic will score over the iPhone 5, and one of the reasons being the support of Flash (emphasis mine): This is a … Continue reading →

Another baffling feature of the new Gawker sites re-design is that it appears that they’ve broken the browser’s Back button. Starting at http://gizmodo.com, I’ll click a link for an article: That brings up the Web 3.0 Frames magic and replaces … Continue reading →

AKA, folks are getting a little too clever in AJAX-land.  There was a joke going around when “new twitter” launched that “old twitter” is what Steve Jobs would have designed if his engineers started with “new twitter”.  Looking at…

AKA, folks are getting a little too clever in AJAX-land.  There was a joke going around when “new twitter” launched that “old twitter” is what Steve Jobs would have designed if his engineers started with “new twitter”.  Looking at any … Continue reading →

A quick way to explain a set of differing opinions is to label it as “a religious argument”.  In a post about using MEF on NerdDinner, Scott Hanselman showed an example on using poor man’s DI versus regular DI.  Now, the post wasn’t about that topic, but more on how to integrate MEF with ASP.NET MVC.  I do get rather annoyed at comments like this however (emphasis mine):

The second constructor takes an IDinnerRepository, allowing us to make different implementations, but the default constructor says, "well, here’s a concrete implementation if you don’t give one." It’s a slippery slope and by adding the default implementation I get to sidestep using dependency injection while making the controller testable, but I’ve tied my controller down with a direct dependency to the DinnersController. This is sometimes called "Poor Man’s IoC" and many would say that this is a very poor man. That’s a religious argument, but Hammett takes a stand by removing the default constructor.

I see a religious argument is an argument whose opposite positions aren’t based in facts, but opinions.  It’s reasoning based on assumptions that are grounded in either faith, ignorance or a matter of opinion.

Something like poor man’s DI versus actual DI is different.  Let’s compare the code.  First, poor man’s DI:

public class DinnersController
{
    private readonly IDinnerRepository dinnerRepository;

    public DinnersController() : this(new DinnerRepository())
    {
    }

    public DinnersController(IDinnerRepository repository)
    {
        dinnerRepository = repository;
    }

Now, regular DI:

public class DinnersController
{
    private readonly IDinnerRepository dinnerRepository;

    public DinnersController(IDinnerRepository repository)
    {
        dinnerRepository = repository;
    }

In comparison, the poor man’s DI example:

• Has more code
• Is coupled to a specific implementation
• Decides its component’s lifecycle

This isn’t just in the controller, every component used must use this technique.  Anything that DinnerRepository uses also would have to employ this technique, as we’re using the no-argument constructor for DinnerRepository.

I don’t know about you, but if I can write less code and gain the benefits of looser coupling and externalizing component lifecycle, that’s a win.

Let’s review.

Poor man’s DI: more code, more coupled, no flexibility

Regular DI: less code, less coupled, high flexibility

It was a failure in teaching dependency injection that the argument was made based on testability.  It only helps those already doing TDD to shape design, rather than just writing tests.

Instead, DI is about creating highly flexible components, both in lifecycle and component selection.  DI removes component resolution responsibilities from classes, therefore removing code.  And less code is ALWAYS a good thing.