Don't Fight the Framework

This is a little less organized than I would like, but I believe the brain dump is worthwhile.

In general I believe there are two types of people out there, those that embrace a framework, and those that fight against it. I’ve generally found myself in the fight against it camp. This post is about my never ending battle with the ASP.NET MVC framework in particular, what led up to it, and the events leading up to my final capitulation.

Why Fight?

These are a few of the reasons why I’ve generally fought against the framework:

Form Elements

What is with the form sytax? Why are there div tags floating around all over the place? Why do we insist on displaying validation error messages inline with the form element instead of in a summary?

This is an example of the output you might get by using Html.EditorForModel().

  <div class="editor-label">
    <label for="Name">Name</label>
  <div class="editor-field">
    <input class="text-box single-line" id="Name" name="Name" type="text" value="">

  <input type="submit" value="login">

What is the purpose of all these div’s? Wouldn’t it be better to customize standard HTML elements instead of having all these classes all over the place? I would personally rather layout my form like this instead of living in the div hell generated when you use Html.EditorForModel().

      <input type="text" name="name" />
      <input type="submit" value="Save" />


Some of these arguments may be valid, but more so when you are working on a project by yourself. They fall apart when you start working as part of a larger team though.

Why Give In?

Yep, there are reasons why you shouldn’t fight the framework as you might have guessed! Here are just a few:


Consistency is pretty key here. What happens when you are bringing new people into a project? Chances are they’ll have experience with the standard features of the framework, but if you’ve deviated from these core standards and rolled your own functionality in many places then you hinder their ability to jump into a project and provide immediate value. Instead of hitting the ground running they end up having to learn “your way” of doing things.

To that end it is much easier to set certain standards within your organization on what you’ll use and when you’ll use it than to roll your own mini-framework on top of the framework.


I’ve written a great many extension methods in the past, particularly to extend HtmlHelper. Through the use of extension methods we can provide slight customizations without completely rocking the boat.


While I sometimes still feel that I’d like to be more of a purist and hand-roll many of these things myself, at the end of the day I no longer feel it a worthwhile endeavor. Just make sure, as I will, that you standardize on the things that make sense to you. You might share my aversion to Html.EditorForModel(), but that doesn’t mean you should turn your back on helper methods like Html.BeginForm() and Html.TextBoxFor().