MVC or WebForms: It's more about client side vs server side - Ian Cooper - CodeBetter.Com
MVC or WebForms: It's more about client side vs server sideScott Guthrie has posted on the growing debate over Webforms vs. MVC, a debate that seems to be raging everywhere (although there is more that one MVC framework out there too). I agree with Scott's point about the nature of technical debates, and the acceptance that there are different schools of thought. However, that does not always imply that all schools are equally good solutions to a given problem.
The issue has been though I think not solely about the MVC pattern, it is also about the shift from providing rich client behavior server-side or client-side. In this area the renewed interest in AJAX and the emergence of Javascript libraries like Prototype, script.aculo.us and JQuery have been game changers. And for me those RIA paradigms dovetail better with MVC apps than with Webforms applications. At the same time the growth of REST has meant many have re-engaged with the HTTP protocol and its resource oriented model, have turned attention away from page based approaches to web development toward resource oriented ones. There is a correspondence here, because as the use of client side scripting grows so does the perspective of the server as a resource provider used by the client.
It is in many ways this shift of paradigm that MVC supports better and why using MVP approaches with WebForms is not a 'seperate but equal' answer to modern web development. Its not simply about better conformance to Single Responsibility Principle.
What our frameworks do for us
Our average web framework has some pretty basic requirements - handle requests for resources from the server by returning an appropriate response. In our case this is HTML. The simple nature of this model underlies the success of the web.
To support this model our framework needs to route to an appropriate handler in our code that can read the request. Now we could just interrogate that request to pull out post data or query strings, but writing a lot of that code would get old fast, so it helps if our framework can map between form, params and query string values and part of our object model. That way we can manipulate the variables of the request more easily. Now we have to take an appropriate action in response to the request. Generally this is where most of our code plugs in. We get some data and compose a response, in HTML to return in the response. Now just using Response.Write() to output our HTML becomes hard to maintain, so most of us expect our framework to give us some sort of template so that we can separate the static and dynamic portions of our response.
The MVC pattern enters the fray here when frameworks separate the responsibilities of template to provide view, model to provide response to action, and co-ordination between the two for a request. Criticism of Webforms as lacking effective separation cf concerns is because the aspx file is both responsible for rendering the HTML used as a response and providing the controller for the request. It thus has two reasons to change, because the template changes or because the co-ordination of handling a request changes. These may be orthogonal concerns and make maintenance harder. Some patterns such as MVP try to alleviate this by enforcing separation of these two responsibilities within the framework. this criticism is valid but not complete issue; the significance of 'MVC' frameworks is not solely their better separation of concerns.
Now for sure the devil is in the details, but that's pretty much it.
Bare Bones
'MVC' frameworks such as ASP.NET MVC or Monorail ttend to have a bare bones approach to meeting these requirements. The framework takes requests and calls an action to service them, mapping request to action parameters. We then carry out the appropriate task and render html through a view engine. MVC frameworks add little on top of this paradigm. The big win here is that this makes them simple to learn and easy to use, because the surface area of the API is small. The surface area for ASP.NET MVC is smaller than that for Webforms and is easier for new developers to learn. It also works in harmony with http and thus expectations. The principle of least surprise is important to APIs because it makes them easier to discover. Understand the problem and you are likely led in search of the solution.
Rich Internet Applications
Now ASP.NET MVC etc. allow you to return an HTML response, but HTML has its limitations in that it is static. You need to post a request to the server each time you want some new action to occur. In some cases this 'complete form and submit' model works, but we have become used, from smart clients, to a more dynamic model that provides feedback as we make selections. We expect choosing from one dropdown such as country to restrict choices such as US State vs. UK county or Post Code vs. Zip Code.
Out-of-the-box support in web browsers for dynamic behaviour came in the form of Javascript and manipulation of the DOM. The browser is the smart client in this approach. The issue here is that Javascript development was a challenge for many developers and consequently many development shops. Why? Because folks found client side behaviour did not just require switching to another language, but also learning the DOM, which was also sometimes uncomfortably close to metal for developers weaned on smart client Forms frameworks like Windows Forms, VB, or PowerBuilder. In addition the browser wars meant that the model for programming against the DOM was not the same from browser to browser, further complicating the code that was needed to implement a rich client in the browser. In truth it was expensive. Finally the debugging experience was poor. We were back to tracing the state of variables in order to isolate and fix problems in the browser. For many MIS departments writing sites with a rich client, heavy on javascript, was out-of-reach in other cost or skills.
To solve this problem WebForms introduces the concept of server side controls - essentially shifting the rich interaction to the server. The server side control abstracts the html control from the client side. The benefit is that it allows you a development approach familiar to forms based programmers. You set and get control properties and write handlers to react to events. But as the events are raised client-side you need effectively mirror all of the control state from the client side to the server. The problem here is that html does not share this with you on a post. You also need to record the event raised for the server side too, as a post is all you know about from http. This brings in ViewState, which captures all the state which a post is not giving you. But once it is implemented I can provide all that dynamic behaviour on the server, skipping and jumping over issues like knowledge of Javascipt and the DOM, as well as browser compatibility issues.
Of course we can quickly see that with any complex enough page ViewState will grow. As it is embedded in a page it increases the page weight which can hamper performance In addition because we must do an http post to transfer the state of our application back to the server, and then display the response, events are handled by a page refresh. This has the consequence of making the system slower than one which handles the event locally, giving rise to user complaints of flicker or slow response. In addition if you try to cope by adding some AJAX callbacks from your client the question quickly becomes 'who owns this state' as you may have copies of the state both on the client and in ViewData being marshalled back and forth to the server.
Webforms is also a more complex API than MVC and thus harder for developers to learn. Most of us have been at an interview where we have asked, or been asked the question - what is the Webforms lifecycle? Understanding the stages, where viewdata is available and modifiable is not an insignificant learning challenge.
Given that, for some time I used to recommend building applications using WebForms server-side control model over building applications with client side behaviour. Why? Because of the cost and difficulty of building rich client behaviour in Javascript with the DOM outweighed the cost of learning Webforms.
What Changed?
MVC trades the complexity of server side controls for a simpler programming model, supported by client side controls. The emergence of the new breed of Javascript frameworks like Prototype, JQuery, and script.aculo.us, made it far cheaper to code the client behaviour on the client. The elegance and simplicity of these frameworks, their abstraction of browser API differences, and their rich ecosystem of control providers, lowered the barrier to entry for client-side development providing solutions to common needs such as grids . The availability of many free controls lowers the cost of common UI widgets that have often been the preserve of expensive vendor solutions.In addition the debugging experience for Javascript has significantly improved from the old trace and dump model with browser plugins such as Firebug and Visual Studio.
With a lower cost it has become commercially viable for more development shops to build rich client applications. Best of breed applications do not suffer from the postback flicker issue because they manipulate state locally on the browser and use AJAX calls to the server. With effective client side development, the user experience is akin to smart clients of yesterday, with none of the distribution problems for central IT departments. This rich experience available for the web lies at the heart of the SaaS revolution.
The MVC model truly shines with AJAX where the target for an AJAX call is just an action on a controller. The affinity to http’s resource based model allows for easy definition of the server side support for rich clients. The advatange of MVC frameworks is the ease with which they dovetail to client-code using frameworks like JQuery. Client-side programming is back, using modern Javascript libraries!
It is this, IMO, which has shifted the balance in favour of MVC. I do not think it any accident that the ASP.NET team shipped JQuery with ASP.NET MVC. I think it was essential to shipping an ASP.NET MVC application that a modern Javascript client library was included to support rich client behaviour on the browser instead of server side.
From my cold dead handsThe attitude of many developers may be ‘you will pry Weforms from my cold dead hands’. The march of progress is threatening to do just that. Much of theresistance is based on prior experiences with the cost of client-side development using Javascript, without understanding that the new frameworks available have significantly lowered the barrier to entry there. In addition, Silverlight opens a second front against Webforms by offering rich client development using XAML. If Javascript does not replace Webforms, then XAML will. Server-side controls had their day. They built careers, companies, and fortunes but they are legacy applications now. Client-side controls have returned with fresh offensives that will see their end. If you are building a new web project today you should be looking at an MVC framework.
For my part the question of Webforms vs. MVC is already an irrelevance. That is yesterday’s fight and victory has been declared despite a few units continuing to fight on. The next war is likely to be between Silverlight and Javascript for ownership of the smart client…
Posted 01-27-2010 3:34 AM by Ian Cooper
Best and most complete article I have ever read about this subject.
Let me underline these two citations, that I subscribe:
"If Javascript does not replace Webforms, then XAML will."
"The next war is likely to be between Silverlight and Javascript for ownership of the smart client…"
Sem comentários:
Enviar um comentário