ASP.NET MVC Controls and Good versus Evil

Luis and David recently posted about the controls that appear in the ASP.NET MVC Futures 1.0 release.

• Luis Abreu: The MVC framework: the Repeater control
• David Hayden: ASP.NET MVC Controls in ASP.NET MVC Futures - Repeater Control Example

I’ve seen some discussions where people positively erupt at any mention of the word “control” in an MVC setting. These are the people who consider ASP.NET Web Forms as the ultimate source of evil in the universe – a cross between a Sith lord and a velociraptor. The idea of introducing controls, with un-testable event handling code and giant gobs of view state, is a travesty that will corrupt the minds of all developers before devouring their children. They must be stopped.  

The Case For Controls

Let’s take the simple scenario of rendering a text input in the browser. If you are using the ASP.NET MVC framework release with no additional libraries, you’ll be looking to use one of the 4 Html helper TextBox methods (excerpted for space below):

string TextBox(... string name);
string TextBox(... string name, object value);
string TextBox(... string name, object value, IDictionary<string, object> htmlAttributes);
string TextBox(... string name, object value, object htmlAttributes);

A text input is a pretty trivial control, but even these 4 options don’t give you a clean path to the entire universe of things you might want to do when displaying a value in a text input, like specifying a formatting string to use when converting the model value to a string. One solution is to write additional helper methods, or include an additional library with the methods already written, but you are only adding to the number of method overloads a developer has to parse when they just want to display a simple text input. In the end, you’ll still be looking at code similar to the following…

<%= Html.TextBox("ReleaseDate",
                 String.Format("{0:d}", Model.ReleaseDate),
                 new { @class = "special" })%>

…versus the declarative syntax of the MVC futures TextBox control…

<mvc:TextBox Name="ReleaseDate" Format="{0:d}"
             class="special" runat="server" />

Note that the MVC control does not inject view state into the rendered output, but that’s not to say that the MVC controls don’t have some issues. One issue is that they still inherit properties, behaviors, and events from System.Web.UI.Control, and some of those inherited features don’t make sense in an MVC view.

I think I'm still happier using Html helpers.

Here are some advantages I see to using controls:

• The declarative model is easier to scan because the named properties are explicit, whereas with HtmlHelpers the order of the unnamed parameters is important.
• It’s easier to add extensibility via additional properties instead of adding yet another extension method overload.
• The logic for a custom control is encapsulated in a class, with all of the benefits of using a class, whereas the entry point for an HtmlHelper is just a method.
• Controls would probably be the preferred way to work for designers (of the human variety).
• Controls would probably open up more opportunities for vendors to ship functionality.

And the disadvantages:

• They remove the benefit of strongly typing the model, which is a huge loss.
• Someone under the influence of the dark side can wire up event handlers.
• It’s possible to build controls that are too smart for their own good (or for the view’s good).
• Nobody knows what HTML might appear when the control renders (which, to be fair, is also true of 3rd party Html helpers).

It’s also worth pointing out that there are other solutions, besides controls, to the often clumsy Html helpers. By sticking to view-specific models, conventions, and effective CSS with JavaScript, you can remove many of the concerns that the HtmlHelpers burden themselves with. Using a view engine other than the web forms view engine can also solve some of these issues.

What do you think?

Will MVC controls be the spawn of Satan, or the blessing of a saint?