ASP.NET MVC – Where Convention Really Matters

I am just going to come out and say it.  Occasionally I break the rules when it comes to conventions. Sometimes it is even on purpose.  In a recent peer code review, I was dinged on two counts of improper naming conventions:

1. The first charge was my use of ALL_CAPS_WITH_UNDERSCORES when naming C# constants. Sure, Pascal casing is recommended, but old habits are hard to kick.  I’ve now conformed to the new, 8-or-so-year-old standard, but boy do I miss the way ALL CAPS made me feel like my code was yelling at me. 
2. My second offense was another ALL CAPS thing.  Despite the standard convention which states all caps should only be used for identifiers that consist of two or fewer letters, if I were doing work for A Big Company, my namespaces would probably read like ABC.Web.UI rather than Abc.Web.UI. I’m not sure when the 3+ letter acronym rule was introduced, but my favorite language (far beyond that of C#) is English and I like the English  rule of capitalizing EVERY SINGLE LETTER in an acronym so I may just stick with it.  I’m bad news. I know.

Conventions have changed as our tools and languages have evolved.  IntelliSense and hover-over help text alone are changing the world one convention at a time.  Hungarian notation is now laughable — although I still use an abridged form when naming my UI elements (e.g. UserLabel, UserTextBox.)  The point is it is hard to not be just a little flippant about things that are constantly changing.  I’m pretty sure that’s why I’m personally a little loose when it comes to the casing of my constants and namespaces.  In the grand scheme of things, these details just don’t matter. 

Where conventions do matter, however, is within opinionated frameworks like ASP.NET MVC.  In ASP.NET MVC, the view (really the ActionResult) returned by the controller is implied per the method name if the view isn’t explicitly called out.  In the example below, the implied view (Delete) is returned if a dinner is found.  Otherwise, we explicitly return the “NotFound” view.

public ActionResult Delete(int id)
{
    Dinner dinner = dinnerRepository.GetDinner(id);
    if (dinner == null)
        return View("NotFound");
    else
        return View(dinner);
}

Unless you are familiar with this convention and you adhere to it, the code can be a little confusing.  If you ask me, conventions within ASP.NET MVC (along with other MVC frameworks like Ruby on Rails and Maverick.NET) are very powerful, convenient and must be respected.  This is a case where conventions really matter.

Another ASP.NET MVC convention dictates where views must be located if they are to be used by the controller.  Working off of the prior example, the DinnersController.cs finds the Delete or NotFound view within the predictable Views\Dinners\ folder and the filenames map directly to the name of the views.

These are somewhat trivial examples of how conventions (over configuration) are used in ASP.NET MVC.  The main idea is that some conventions are handy, purposeful and necessary.  Other conventions don’t really carry that much weight. 

If you are interested in reading more about how conventions and standards, check out one of my older articles about compile coding standards and the devil being in the details.

If you are interested in learning more about ASP.NET MVC, this write up is leveraging code and screen shots from NerdDinner ASP.NET MVC tutorial. You can download the free end-to-end tutorial chapter in PDF form and download the source code + unit tests for the completed application. I spent a couple of days working through the documentation and sample project.  It is truly an excellent introduction into ASP.NET MVC.