ASP.NET MVC, front-to-back advantage revisited

A couple of month ago, I wrote a post about the surprising advantage of MVC as an enabling technology for front end folks. The more I work with it, the more I feel that it's the key advantage to using MVC. Given my rants on why I think the user experience is so important, you can understand why I'm so excited by this.

The shift in thinking to making more UX magic on the client end does throw us back into the world of Javascript, which is at least a little unfortunate since the debugging tools aren't nearly as good as the back end, but with jQuery and countless plugins easing the pain, I continue to be amazed at how quickly you can turn out really nice experiences. And even more surprising is that it doesn't require all kinds of drag-and-drop tools. You really get into the weeds with actual code, but without a ton of complexity.

What am I rambling about exactly? Your client code is often a couple of lines of code to make a JSON call or activate graphical notifiers, while your server code is often little more than a simple controller action. Even in the best encapsulation of script and rendering code in standard Web controls for Webforms, it's never that clean.

The question in my mind now is, what happens when ASP.NET v4 is out? With a much higher degree of rendering control, the "cleanliness" issues may be largely addressed when it comes to writing the client code. Will it still be as compelling?

I'm curious to hear stories from developers on how MVC is making their lives easier (or harder).


  • Hi Jeff,

    While I have probably spent 20 or so hours reading up on ASP.NET MVC, and watching PDC and Mix videos, I am still using WinForms for most stuff, along with some client side jquery where it makes sense. I am not new to MVC, as my previous company was using it on the java side for over 10 years.

    While I acknowledge ASP.NET MVC is clean and elegant, I still think it needs a v2 or v3 (at least a full control model and bunch of higher level controls), contrast to WebForms which by now is very mature. For me ASP.NET MVC does not reach the threshold (yet) where it would be worth me mastering it to the level I have mastered ASP.NET WebForms.

    I find with WebForms I can implement 95% of the site, even including lots of UpdatePanels, and provided I enable HTTP Compression on the server, and minimise ViewState, my request/response packets only end up 1 KB or so - and usually happen in under 1/10th a second. So the WebForms and the UpdatePanel are really not that bad if you understand the model and know what ViewState is, etc.

    For the other 5% where I really do need incredible client side interactivity (or more async stuff), I am using both ASP.NET Ajax and jquery - and hitting json web service proxies for the backend service. But even in those cases it is executing in the context of a WebForm.

    So while ASP.NET MVC is nice and elegant, and I respect it immensely as a solution, it is not worth my time at the moment. Although that said....I have many friends on the java side in the constituency where they would only even look at .NET if it used MVC as it is the 'only way'. So I love that MVC broadens the platform, provides options, and agree it is an elegant framework.

    Hope that feedback helps.


  • Jeff,

    I should add that while I will enjoy the extra control over Client ID's in ASP.NET WebForms 4, it does not trouble me that much as when accessing ASP.NET Controls from script I just include a line in my javascript like this:

    var myControlClientID = '';
    // of javascript code

    Benefit being that the ASP.NET compiler (when you hit compile in Visual Studio) will actually give you an error if you rename MyControl, and forget to update that javascript line!

    You can obviously factor your javascript code to be mostly in an external script file, but include that code on the ASPX page to bundle up the controls you want access to from script.

    Other than that I use CSS class selectors (from jquery) and often just add dummy classes such as:
    class='deepBlue jMyControl'
    Note my own convension is to put a 'j' in front of dummy CSS classes that I only use for selectors in jquery/ASP.NET Ajax Client Library.

    So...sure, more control over Client ID will be nice, but I have not found it a huge problem.


  • I'm really with you on looking forward to a future version. The control issue, the lack of out-of-the-box robustness, is definitely something that I hope can be expanded on.

    There's no question that Webforms can do pretty much 100% of what anyone may need, as far as I'm concerned. What I'm fishing for is more along the lines of whether or not MVC really causes a disruption in process and approach.

Comments have been disabled for this content.