Maybe more specifically Microsoft’s Update Panel mechanism for AJAX may be something to avoid from time to time as it posts back everything and in some cases (as they have noted) it can be slower than a normal post back. It is certainly a nice idea, to make developers not worry about the JavaScript plumbing needed for it, but that is perhaps another example of an abstraction that leaks (kind of).

As I said in the article, if you are aware of the various issues then you are better prepared to use them if needed – its all appropriate trade-offs at the end of the day – there are times when we’ve opted to use Update Panels in certain circumstances for our back office app where pragmatic (the cost of refactoring/rewriting the controls that take part in the Update Panel was too high, for example).

Since writing the above (a long time ago now), MS have of course embraced jQuery which has a lot of ajax capabilities which you can control more, too.

The Joel Spolsky quote I used had an example (link buttons that require javascript to post back when clicking a link and don’t work with JS turned off).

The article was specifically about the frustrations that ASP.NET Web Forms has for web developers who want a lot of control over the markup produced. Of course, HTML/JavaScript/CSS are themselves abstractions (with their own leaks!). Everything on top of 1′s and 0′s are an abstraction, so I am not saying that leaky abstractions are bad per se.

My specific gripe at the time was about control of markup being difficult with ASP.NET Web Forms. Especially where client side performance, accessibility, progressive design type of concerns have long put off many web developers and designers from working with ASP.NET, which is a shame as much of the .NET platform is quite powerful.

Since writing the above article (about 3.5 years ago) ASP.NET MVC has come out. In my opinion, their MVC implementation is really good and from what I can understand of the various reasons MS came out with it, one of them included the ability to provide web developers better markup control (as well as improving testability, and so on). That alone tells me they recognized that the markup control was a particular issue they wanted to address.

(ASP.NET MVC had just started to come out when I wrote the above article so didn’t mention it as much as I hadn’t really looked at it then though some others did in the comments). Since then, I’d be really willing to consider MVC over the above-suggested XSLT approach which has worked well in some scenarios.)

Nikhil Kothari’s comment above also hints that for the time ASP.NET was created it was probably what their target audience needed, which is fair enough. But just a few short years after it was out, the landscape had already changed; a lot of developers wanted more markup control and it isn’t easy in an ASP.NET Web Forms world (certainly not impossible as I also note).

ASP.NET MVC certainly feels like it has addressed this particular problem. I should probably update the title of this page now to say ASP.NET *Web Forms* is a Leaky Abstraction, anyway

Joel does go on to say that you are pretty much guaranteed leaking in any reasonably complex abstraction, so I think its wrong to present it as a solvable problem. Or as something uniquely bad in ASP.NET…

If an abstraction of web page development were to be entirely non-leaky it would not be an abstraction at all, it would in fact be a translation.

Lets be quite clear, abstraction (even in its inevitable leaky form) is a VERY good thing. Without it we would all have to know everything about the lowest level details of every task we undertake and productivity would literally seize up.

The story of software development is the story of increasing abstraction. Its unwise to try and stand in the way of this march of progress! ;>)

We just do not have the capability or capacity (or the inclination) to train the numbers of people required to learn the non-abstracted version of web development.

Now we come to the more subtle point that every abstraction of a domain will leak in different ways.

Maybe you just don’t like the ways that the ASP.NET abstraction leaks?

Or maybe you are a die-hard purist and can live without any abstraction of web development at all – well, that too is fine but what about the rest of us mortals?!

I think its actually quite an “elite” view to give the impression that the millions of useful/interesting/valuable web pages produced by this ASP.NET abstraction are somehow not of any worth?

And if you don’t think they are worthless (don’t want to put words in your mouth!), then you surely have to give some credit to the “leaky abstraction” of ASP.NET that allowed people to produce them?

Let me put it another way, not every machine that people use to perform useful/valuable/enriching work or leisure has to be an example of the finest engineering.

Its like saying we must all be driving around in highly engineered Ferraris, when for most of us we can get what we want from a car with a Nissan.

I think there is a certain purist attitude (which I can understand) that is offended by these “awful Nissans” filling up the pages of the web with their poor underlying engineering.

But the truth is if they do the job they are intended for then that is my definition of perfect engineering.

All-in-all a great article though and very thought provoking!

http://devlicio.us/blogs/vinull/archive/2008/07/25/the-mvc-minefield.aspx

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.