ASP.NET MVC Controls and Good versus Evil

Thursday, April 9, 2009

Good Unicorn versus Evil UnicornLuis and David recently posted about the controls that appear in the ASP.NET MVC Futures 1.0 release.

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?


Comments
Stan Thursday, April 9, 2009
Controls are the black unicorn. It must be slayed. THough I kind of like the skull it has on its rump, reminds me of my wife.
Kevin Dente Thursday, April 9, 2009
I vote nay on controls. In addition to the downsides you mention, they are view-engine specific.

It looks to me that the primary purpose of them is designability. But since I generally find the webforms designer to be mostly useless in any real app, that feature doesn't mean much to me.

Another possible solution to HtmlHelper overload hell is the fluent HTML builder interface like the one included in MvcContrib.
Aleš Roub&amp;#237;ček Thursday, April 9, 2009
I'm working on ASP.NET MVC project and introduced strongly typed MVC controls (repeaters etc.). The idea is simple, i use contracts to load data from ViewData.Model. WebDesigner then can use templated controls with hight semantics and developer implement reqiured interface in view model...
Luke Thursday, April 9, 2009
When C# 4.0 is out, some of the advantages listed for controls will be applicable to helper methods through the use of named parameters ie you won't need to have multiple overloads, and you will be able to clearly see what parameters are being set.
scott Thursday, April 9, 2009
@Luke - C# 4.0 - good point.

@Ales - This is a fantastic idea. Looks like you have some interesting blog posts. I'm trying to translate them now.

@Kev - Yep.

@Stan - Your wife has a skull on her rump?
Ben Scheirman Thursday, April 9, 2009
+10 to what Kevin Dente said.

The only scenario that I see that makes sense is if you want a control to emit its own script, etc at the HEAD of the page.

With MVC, you don't get anything you don't ask for, so this sort of goes against that experience. I don't mind so much anyway, since you have more control (you could combine/gzip the js files easily for example).
mogadanez Thursday, April 9, 2009
you forgot third way:
simle
<input type="text" name="ReleaseDate"
value ='<%=String.Format("{0:d}", Model.ReleaseDate)%>' class="special" />

not greatly more than control.
mogadanez Thursday, April 9, 2009
2Ben Scheirman
in Another ViewEngines is NO issue with head title and emit some css/js to head.

Rick Thursday, April 9, 2009
I've found myself creating simple classes, and overloading the ToString() method as a Render. In this case:

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

The problem is of course, getting the reference to the model.
Joe Thursday, April 9, 2009
probably a bad idea in the long run, but short-term probably a good way to get less enthusiastic co-workers to migrate....
Khaja Minhajuddin Friday, April 10, 2009
Controls and MVC shouldn't be used in the same sentence! Let's not add things just to please everybody out there.
&amp;#216;yvind Fanebust Friday, April 10, 2009
Spawn of satan! No doubt.
Scott Friday, April 10, 2009
So lets say you are writing out a table or a form using a lot of HTML helpers and you decide to combine all of them into one large helper call. Haven't you basically written a control at that point?
scott Friday, April 10, 2009
@Scott - It's a fine line, isn't it?
Stephen Tuesday, April 14, 2009
I think this 'kill all controls' thing is idiotic, seems like theres a lot of sheeping going on, no info and lots of 'stay away or we'll burn your house, heathen!'

Personally the declarative approach is much better, I don't see how either is more testable.. declarative or monolithic overload hell? hmm, what are we testing? and how is it inherantly flawed in a declarative system.

I think what most people mean is.. System.Web.UI.Control is evil, and yes - yes it is.
Stephen Tuesday, April 14, 2009
Additionally, Rick - your solution is already much better than the helpers solution.
jmorris Wednesday, April 15, 2009
No...no, pleeeeeez no. Actually, it wouldn't matter for me, but you will see (i imagine) a ton of code behind in the views.

Even in a webforms environment I don't use any of the asp controls unless I absolutely have to...and then I throw up ever so slightly in my mouth.

-J
John Rusk Sunday, April 19, 2009
>They remove the benefit of strongly typing the model, which is a huge loss

Is that because they data bind to a property via a string name?

On my current ASP.NET project, we are solving that particular problem by using lambda expressions rather than strings, to define the bindings. I wonder if there would be any way to achieve a similar result with MVC controls......?
gravatar MikeM Saturday, March 6, 2010
I know I am way late at posting on this, but this is the first hit when I google "asp.net mvc controls."

The problem here is that the greatest thing about MVC is control over the markup. For that reason I generally don't use HtmlHelpers either except in specialized cases that don't affect "content", such as some custom extensions to manage script references.

I recently started using the Spark view engine, and all I can say is, oh my God, away with the WebForms view engine already!

Why are we even trying to work around the limitations of that view engine when there is such a better alternative out there already, which fits the MVC model way better? What MVC needs is "official" backing of a view engine that embraces HTML and is designed with MVC in mind.

Right now, the "official" MVC release is a big hack around the WebForms model.

If Microsoft is really backing MVC, I don't see why they would have any problem providing the MVC team with the WebForms view engine code so you can customize it.

What I would really like to see is a view engine that maintains ASP.NET binding syntax for familiarity, but adds the declarative Spark attributes and elements for condition testing and looping. That would be a big win in my books.
J&#243;n Trausti Monday, June 7, 2010
Thanks for the neat blog.

I am one of those who simply hate WebForms and love doing clean and beautiful HTML code. As a part of the solution I moved to MVC.
What I dislike about MVC is how the view can get really ugly.

Thanks to MikeM above, I just found out about the Spark View engine, which seems to solve many problems with the view!

But I do wonder what the future may look like for ASP.NET's MVC. People were sharing neat things such as a calendar control to each other by creating custom controls. How will this be done in MVC without any controls? I personally think there needs to be a new solution, outside the box.
gravatar Brian B Friday, June 25, 2010
I'm just now playing around with MVC, and the WHOLE REASON I don't like it is b/c there aren't any controls for it yet.

I don't understand the control-haters out there. My users demand very complex grids. Sorting by clicking on the column header, scrollable rows with fixed column header, edit within the grid, etc. You want me to roll this from scratch?? And do it on every form with a grid? A ridiculous concept and my clients will never hire me again after my bill quadruples. But you say, "We want clean HTML!!!!" Yeah, well you also want a website with no functionality then.

Confused.
gravatar Doug Kimzey Friday, August 13, 2010
In playing with MVC controls from DevExpress and Telerik - MVC controls fulfill the requirement of supplying your user with a powerful and feature rich grid (or other control) without embarking on a development effort that reproduces the functionality of off-the-shelf controls. On the down side - it can be very confusing when you have an honest need to handle a control event. After all, there is nothing like a HANDLES in MVC (or at least nothing I have seen). This leads to cases where you write partial views, views and controllers that; more-or-less; handle control events but; apart from comments; have absolutely no clear connection to the control or the control event. In my mind; this is a strong negative against the combination of MVC and controls.

But, I have a real and stronger need to not re-invent the wheel with each new development effort. So I like and need controls. I also like MVC (not convinced about need yet).

If I have a client with a website that contains familiar and easy-to-use controls, I am going to think twice about dumping the control, just to go to MVC. I am going to think three times before I try to justify the cost (and their bill).

MVC capable of supporting controls (and somthing like events) is far preferable than MVC alone.
Billb Wednesday, October 13, 2010
What about http://jqueryui.com/ and the like? And this:
stackoverflow.com/.../jquery-grid-recommendations

Is that where MVC devs should look for so-called controls?

Bill
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!