Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
The MVC Minefield

There is a bit of turbulence in the ASP.NET airspace over MVC (yes, I'm making this post while on the fight back from the ASPInsiders Summit).  Even among the ASPInsiders, who are supposed to be at the cutting edge of ASP.NET, there is little agreement over what is MVC and what it's for.

MVC, or Model View Controller, is an age old pattern found in many places.  ASP.NET providers follow the pattern, as does Service Oriented Architecture.  The general idea to have some code called a Model that works with your data storage, other code called a View that displays the data, and last plumbing code that ties these two together, called the Controller.  I call it a pattern because implementations differ in the details - the View may render a button, but when the user clicks that button should the click action be handled by the View or Controller?  The Model and View should know nothing of each other, but is the Controller allowed to be tightly coupled to them both?  (If your first thought above was the Controller should handle the button action, think now what this means about being loosely coupled between the View and Controller).

ASP.NET MVC is a framework in development that is intended to closely match the MVC pattern.  The minefield lies in answering the pragmatic question of what does ASP.NET MVC offer over WebForms, and when would you use MVC?  In taking with those excited by MVC the reasons range from supporting TDD, clean URLs and avoiding postbacks by sending actions to a controller, better control over HTML output (including getting rid of ViewState), and being closer to the http protocol.

TDD, or Test Driven Development, will always come up in any ASP.NET MVC conversation, but TDD itself isn't an explicit part of MVC.  The MVC pattern is very amendable to TDD however, and thus the association.  I generally support testable code even if there are no tests around the code.  Testable code is much easier to maintain, enhance, refractor, and replace.  I don't find the process of test-first development helpful, but I do write tests in the same session as the code when I know I'm writing some critical piece of functionality that needs to survive multiple versions of the software.  As Hanselman noted, I'm like the "person who goes to church on Easter and Christmas" and I'm sometimes looked down upon by the congregation who attend weekly.  I'm okay with this, but I have some reservations with MVC as a framework for TDD.

To say you cannot test WebForms is a strawman argument; there is no trouble in separating the Model and testing it thoroughly.  Depending on how you go about it, you can also separate the Controllers and test them - I generally have very simple Controllers that pass user input into the Model as is, so testing the Controller is not that important to me.  Testing the View in WebForms is very difficult - and this isn't specific to WebForms.  My objection to claiming MVC has testable Views is the implied definition of testing.  Verifying the output HTML of a View is not helpful at all - it's just string comparison.   I want to write tests like Asset.JavascriptRunsOnSafariMac() and Assert.IE8RendersSameAsFireFox3().  If MVC could do that, then I would be switching to it today!

WebForms provides a very robust SiteMapProvider interface that makes it easy to clean up urls of dynamic content.  Global.asax can be using to control routing of requests (in fact this is how MVC does it as well).  The biggest problem I've had here isn't WebForms fault, but IIS6's inability to allow ASP.NET to handle requests without an ASP.NET extension in them: this is solved in IIS7.

You can get fine grain control of HTML in WebForms, ever with just the stock controls.  There is also an entire collection of HTML server controls to match HTML tags to make it easy to generate HTML from code (I hate seeing tags hardcoded in source file, feels dirty and hackish).  About the one thing that is hard to do in WebForms I deal with somewhat often is controlling the client side ID's, which can become quite long and fugly looking.  For CSS you can just assign a class name instead of using ID references (and there aren't many places I'm using CSS IDs except for layout divs that aren't coming from ASP.NET controls anyway).  Javascript is trickier; you need to inject a reference of Control.ClientID on the server in the client script, and the need is much more common than with CSS.  If you have an external JavaScript file this can get worse, but I believe that an external JS method should take the ID of the control they work with as a parameter making it easier to read the external file without the need to reference the aspx code.  At the end of the day however, I'm not willing to throw the "baby out with the bath water" and will lean more on Microsoft to fix this issue in WebForms rather than jump to MVC.

The last reason for MVC I mentioned, being closer to the http protocol and its stateless nature, I simply don't grok.  Any application with a basic level of user interaction will need to mask the http protocol's implementation details to provide a positive user experience.  Web programmers of all frameworks and languages have realized there are only a few methods to solve this problem; cookies, url parameters, and hidden fields.  Any state solution will involve one or all of these - even if state is stored on the server's side.  WebForms supports all of these methods, and you can disable things like ViewState (hidden fields) if desired.  (I am aware there is also ControlState that will be still emitted if ViewState is disabled, but I'm willing to say that if these few bytes are an impact you are working on an edge case).

I'm not here to bash ASP.NET MVC - to the contrary I'm here to help by outlining the faults in the current arguments for MVC.  If MVC is defined by the features in or not in WebForms, then it's going to be hard for those deep into WebForms to see value in MVC.  It becomes a song of "anything you can do, I can do better (no you can't, yes I can)" and will deadlock when neither side is listening to the other.  ASP.NET MVC need to be defined without claiming faults in WebForms, because that only says use MVC because WebForms is broken - leading one to say, "why not just fix WebForms?"

I wish I could end here with a new explanation of ASP.MVC meeting the requirements I've just stated, but I'm afraid I can't.  This is a fault with me, and not the MVC framework - I'm too close and deep into WebForms to see a need for MVC I can't fill already.  It's my hope and request that instead of seeking to pick apart this post, the supporters of MVC come out to define MVC without attaching that definition to the perceived faults (for that's the minefield) of WebForms.


Posted 07-25-2008 12:22 AM by Michael C. Neel
Filed under: , ,

[Advertisement]

Comments

Igor Loginov wrote re: The MVC Minefield
on 07-25-2008 6:50 AM

Michael,

Thank you for publishing your thoughts here. Similar ideas are in my head...

As for me, code behind provides the necessary separation of concerns, working as a controller. ASPX/ASCX is a view (pretty clean conceptually if avoid declarative data sources). So, MVC pattern exists in WebForms. I also like the idea of MasterPage and WebControl, that give me additional levels of separation.

On the dark side there are some problems. Most of them are concentrated around two things: ViewState and ScriptManager. What is problematic?

ViewState/ControlState processing is in the beginning of life cycle. Events where we can create dynamic controls fire later. It leads to troubles with dynamic control substitution (one on 1st load, another one on PostBack). Of course, there is work around. We can create both controls and manipulate their visibility. But I would prefer more natural solution - a kind of switching autopilot off and taking manual control over ViewState/ControlState.

The situation with dynamic control substitution becomes a nightmare with AJAX. CallBack carries out the whole collection of ViewState/ControlState every time.

ViewState related problem is internal WebControl naming conventions. It additionally extends the hidden field. But it's clearly possible to store page control tree on server side and to have short node numbers instead of long compound names in ViewState.

ScriptManager. It's not an issue by itself. The issue is that there is no HeadControl concept. Developers need to get access to page title, meta, script, etc. tags from WebControl. And once again MSFT guys do not give manual control of that.

OK. I am completely agree with you, that it's too early to bury  WebForms. But some efforts to keep them competitive are definitely required.

Igor Loginov wrote re: The MVC Minefield
on 07-25-2008 6:51 AM

Michael,

Thank you for publishing your thoughts here. Similar ideas are in my head...

As for me, code behind provides the necessary separation of concerns, working as a controller. ASPX/ASCX is a view (pretty clean conceptually if avoid declarative data sources). So, MVC pattern exists in WebForms. I also like the idea of MasterPage and WebControl, that give me additional levels of separation.

On the dark side there are some problems. Most of them are concentrated around two things: ViewState and ScriptManager. What is problematic?

ViewState/ControlState processing is in the beginning of life cycle. Events where we can create dynamic controls fire later. It leads to troubles with dynamic control substitution (one on 1st load, another one on PostBack). Of course, there is work around. We can create both controls and manipulate their visibility. But I would prefer more natural solution - a kind of switching autopilot off and taking manual control over ViewState/ControlState.

The situation with dynamic control substitution becomes a nightmare with AJAX. CallBack carries out the whole collection of ViewState/ControlState every time.

ViewState related problem is internal WebControl naming conventions. It additionally extends the hidden field. But it's clearly possible to store page control tree on server side and to have short node numbers instead of long compound names in ViewState.

ScriptManager. It's not an issue by itself. The issue is that there is no HeadControl concept. Developers need to get access to page title, meta, script, etc. tags from WebControl. And once again MSFT guys do not give manual control of that.

OK. I am completely agree with you, that it's too early to bury  WebForms. But some efforts to keep them competitive are definitely required.

Dew Drop - July 25, 2008 | Alvin Ashcraft's Morning Dew wrote Dew Drop - July 25, 2008 | Alvin Ashcraft's Morning Dew
on 07-25-2008 7:59 AM

Pingback from  Dew Drop - July 25, 2008 | Alvin Ashcraft's Morning Dew

Joshua Flanagan wrote re: The MVC Minefield
on 07-25-2008 8:14 AM

"it's going to be hard for those deep into WebForms to see value in MVC"

I assume this is exactly why Microsoft has repeatedly stated that they will continue to support both models - they don't want to force people to choose.

If you don't care about the things the MVC offers, if you see the arguments above as nitpicks and you are fine with the little pains you have to deal with in webforms, then you can continue to use WebForms. Either these things matter to you or they don't.

These are not "faults in the arguments for MVC", they are just reasons that are not compelling enough for you.

Derik Whittaker wrote re: The MVC Minefield
on 07-25-2008 8:24 AM

As someone how has been neck deep in winforms world for the better part of 5 years i have to say that to me MVC just makes more sense to me.

I do not have to worry about a bunch of stuff like the view state or post back.  Having to learn and master both of these concepts takes time and if done wrong can screw up a site.

To me, MVC is about choice.  When creating my most recent site  (really only site) I chose MVC because I felt that i could whip out a site faster as well as maintain it better.

The great news is that both MVC and Asp.Net (classic if you will) will both be around for the long run.

ASP.NET MVC Archived Blog Posts, Page 1 wrote ASP.NET MVC Archived Blog Posts, Page 1
on 07-25-2008 9:35 AM

Pingback from  ASP.NET MVC Archived Blog Posts, Page 1

Rob Eisenberg wrote re: The MVC Minefield
on 07-25-2008 10:51 AM

I have to agree with Derik.  I was developing some pretty serious WebForms applications for about 3 years before I tried building something with Monorail.  I remember when I got my first Controller/View working.  I thought to myself "That's it?  That's all it takes to add a new feature?"  I was totally flabbergasted by how easy it was to build the application. It was fun, it worked and it was architecturally sound without me having to think too much about it.  When it comes to WebForms vs. MVC, I don't think there is anything you can do with the one that you can't do with the other, but I do think that certain scenarios are simpler or more straight forward with an MVC framework.  Particularly, I was blown away by how nicely the MVC style works with Ajax.  The time it takes us to build the same application with an MVC framework vs. WebForms is dramatically less (and I remind you, we're no slouches with WebForms).  Thus, we have the ability to offer more to our clients for the same price, and they like that.

Steve wrote re: The MVC Minefield
on 07-25-2008 8:55 PM

I prefer to be closer to the ground with the MVC than the abstraction that Webforms provide.  Webforms is very heavy.  It's fairly easy to quickly start to create the spaghetti code that it was originally designed to be freed from.

I can easily use 1000s of controls made out there, I'm not limited to 'Webform' proprietary controls.  They integrate and play well in MVC - mostly because it's friendlier for client side development.    Webforms is a server-side model, heavy in that.

Compare creating a control in jQuery vs. a Webform control.  

Lastly, I think MVC is a design pattern that is understood and practiced by many web developers outside of MS.  What seems like new candy for MS developers is really a tried and true approach by many frameworks.  That is refreshing to see.

I know the hard and fast hardliner webform guys don't want to see change, webforms has helped bring home the bacon, but I glad just to see alternatives in the MS world, alternatives == choices and having choices helps all of us.

As a contractor, I will cringe at having to go back to webforms  :)  I've really enjoyed what asp.net mvc is bringing to the table

Brian Johnston wrote re: The MVC Minefield
on 07-25-2008 11:41 PM

I've been using web forms since the beginning.  I personally feel ASP.NET MVC is over-hyped marketing explicitly created to compete again MR, RoR, etc.  I've never had a big issue using them - but then I concentrate on have a good set of requirements, and business model before I even begin to think about 'views' - maybe that's why.  In fact Views are one of the last things I think about.

I actually find using ASP.NET MVC forces me to have a tendency to end up going down more of an ERD driven application which results in the exact type of application I don't want to give our users (if you've read 'The Inmates are Running the Asylum' you'll understand why).

But to each his own, and it's just another tool in the tool box and I'm sure I'll use it at some point for a project that specifically needs that type of architecture.

Brian Johnston wrote re: The MVC Minefield
on 07-25-2008 11:46 PM

@Steve - I think MVC is a very *mis*understood pattern - there wouldn't be so many people out there selling it if it was the silver bullet it's made out to be.   People would come to it without have to have it publicized everywhere.  It's kind of like politicians...the more they advertise how much better they are than the other guy...the less I believe them.

The 'spagetti comment' - You can create a huge rotting bowl of spagetti with MVC too - want to see the 859,891 LOC in the application I inherited?  It's been a refactoring joy!    A foolish carpenter blames the hammer when he hits his hand man!

Lucas Goodwin wrote re: The MVC Minefield
on 07-26-2008 12:09 AM

@Michael

My group actually only moved to WebForms about 3 years ago.  We still have 100,000s of LOC in Classic ASP to maintain.  As such we really felt the pain of WebForms.  Namely the disconnect of an event model in a system that's not event oriented.

The way I look at it, ASP.NET MVC isn't throwing the baby out with the bath water, but rather retrieving the baby from Classic ASP and dumping the bath water of WebForms.  People don't like to admit it, but Classic ASP was REALLY damn good at rendering HTML and creating maintainable pages, if you ignore all the downsides of classic ASP that is (DataAccess, not compiled, no or poor debugging, topdown execution nature, etc).

MVC gives us all the goodness of WebForms with out ViewState and a horribly over-complicated event model.  It also allows for a true seperation of concerns for the client.  Why should my serverside code care one lick about what javascript library I'm using to create a certain control (Beyond ensuring the library is included ofcourse)?  That's just one of many examples of how WebForms throws up roadblocks.

Yes, you can develop custom controls, etc (and we have), but that's just added work for no additional benefit to me or the customer.

Brian Johnston wrote re: The MVC Minefield
on 07-26-2008 12:16 AM

I forgot this one other thing I saw out there recently on the subject and good read for anyone whose posted thus far...good thoughts on the subject

www.codinghorror.com/.../001155.html

Michael C. Neel wrote re: The MVC Minefield
on 07-26-2008 11:28 AM

@Lucas Goodwin thank you for your comment - I think you're on to something there.  (ASP.NET) MVC is the evolution of Classic ASP.  I 100% agree that there is nothing but name to link Classic ASP and ASP.NET WebForms together; over the years helping Classic ASP devs grok ASP.NET everyone of them has said "this is nothing like ASP!" when it "clicked" for them.

The ASP.NET MVC Definition - ViNull, Off the Record wrote The ASP.NET MVC Definition - ViNull, Off the Record
on 07-26-2008 12:35 PM

Pingback from  The ASP.NET MVC Definition - ViNull, Off the Record

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)