Hello Everybody,

I post this new article to discuss a topic dear to my web developer's heart and mind. My personnal and experienced opinion on the two main ASP.NET development approaches. The initial single ASP.NET WebForms pattern and the more recent ASP.NET MVC approach. I will enumerate the main advantages and drawbacks of both approaches. I will then give you my preference and explicit my opinions.

 

ASP.NET WebForms

WebForms is the original pattern introduced with the first versions of ASP.NET.

Page oriented

WebForms pattern is page oriented, it means that a page is accessed by entering a URL in the browser, and this page is responsible for executing the whole logic necessary for processing the request from the user.   The page is an ASPX file containing some HTML and ASP.NET specific XML elements. This ASPX file is usually bound to a code behind file (C# or VB.NET).

Benefits

• The main benefit of the page oriented aspect is that the developer can clearly identify the part of the application that will be reached by the user.

Drawbacks

• No special drawback for the page oriented aspect.

Event-driven

ASP.NET WebForms is very similar to the .NET WinForms application model with a bunch of events that can be handled by custom code. These events are raised in a certain order. It is the page lifecycle, and this order could vary according to the context and this could lead to inconsistency in the application design. The workflow of the application is driven by the events raised during the page lifecycle. the events triggered by the user (such as a button click or a dropdown list selection change) result, by default, in a postback, it means a new HTTP POST request on the currently displayed page. This approach implies that the page should have a specific behavior for both contexts:

• HTTP GET for the initial display
• HTTP POST for handling any action from the user

The events approach allows a developer to program as he would in a WinForms application. However, while a WinForms application is usually a single process and events are just a code sequence in memory, In WebForms, events are actually translated into one or several HTTP requests and responses and the page objects are actually recreated with each requests.

Benefits

• The main advantage of events in WebForms is that WinForms developers new to web development will stay in a known environment, indeed, the events are very similar to what we could find in the WinForms context.
• There is an abstraction layer above the HTTP mechanism that allow a developer new to the Web to get a working application pretty easily and quickly.

Drawbacks

• This abstraction layer over HTTP that could be an advantage is also, according to me, the real big disadvantage of ASP.NET WebForms. Because of the abstraction, it is very easy to do ugly things in terms of Web development (as well as design, performance and so on...).
• A developer is able with WebForms to create a fully functionnal application without knowing anything about HTTP, this is, again according to me, another real bad thing.

A large toolbox for productivity

The WebForms, again, very similar to WinForms, allows the developer to use a set of controls and even create his custom ones. A control is a reusable entity that usually results in a rendered piece of HTML code. The developer use a custom aspx tag in the ASPX page, or could even drag and drop the control from the toolbox. This enables the developer to build his application with some functionnal blocks to connect to each other and rapidly get an output close to the expected one.

Benefits

• It is really easy to build a User Interface doing some drag and drop.
• Controls concept is the same as controls in WinForms dear to WinForms developers.
• Controls behaviors are handled again by events. The WinForms developer is, once again, in his playground.

Drawbacks

• It is very hard to predict before runtime what the HTML output will looks like, nowadays, with client side scripting becoming more and more important, the HTML structure must be known as much as possible.
• A developer that only works with ASPX controls tends to forget what is HTML and what is not.
• The event handling of the controls result again in underlying HTTP request processing.

HTTP Stateless handling

As the caption says, HyperText Transfert Protocol is Stateless. It means that there is no correlation in the HTTP protocol between two distinct requests. It also means that when you click on a link in a page, a request will be sent to the server without knowing anything about the last request you made. Let's take an example: You are on an online product ordering form, you enter an invalid e-mail address and submit the form. In this form submission, all values are transmitted, the server realizes the e-mail address is invalid and redirect you back to the form. You would not want to re-enter all valid data for a single invalid field. ASP.NET WebForms comes with some mechanisms to handle this (e.g. the ViewState). The ViewState is a way to work around the stateless nature of HTTP, it keeps the serialized state in a HTML hidden field ( ) and deserializes it when recreating the page, this state is then embedded in the HTTP response which means the response payload is increased. The ViewState is enabled by default on almost every controls, it is possible to disable it, but that will change some behaviors and the developer will have to take special care on how he will handle the state and what will be the application behavior.

Benefits

• The application seems to be stateful by default.
• Extra code should not be written to maintain a state in the application.

Drawbacks

• Again, we get away from the true HTTP context, we have an abstraction of what is actually happening, In the code, the page seems to be the same object, however, it is not and some of its members, properties and so on could be different or have a different, or unpredicted value.
• The events lifecycle of the page MUST be very well known by the developer because the ViewState values are only deserialized at a certain step of the lifecycle and the state values cannot be used anywhere in the lifecycle.
• The ViewState can significantly increase the size of the HTTP request.
• The ViewState is, by default, stored in an HTML hidden field and is encrypted, when you try to see the HTML source of the page, you will see a large block of unreadable content which is the ViewState

 

ASP.NET MVC

A few years ago,  ASP.NET introduced the MVC approach which stick to the Model-View-Controller design pattern. I think this pattern is much more suitable to a request/response protocol such as HTTP because the workflow is really more structured and each part of the application is dedicated to a well defined part of the business process.

History and definition

The MVC design pattern has been introduced in the late 70's by Trygve M. H. Reenskaug. This pattern uses 3 main components:

• The model which is basically any data that the application will work on.
• The view which is the interface the user will use to interact with the application, it will present the information to the user and relay all the user's action to the application.
• The controller which is responsible of managing the events, order the different operations on the model and synchronize the changes with the views.

While the controller can act on both views and model, the view is only able to read information from the model and present it, the model doesn't know anything about the view but only the data it is responsible for and the logic applied on it.

Applied to ASP.NET

ASP.NET will handle an HTTP request and give the hand to the appropriate controller, the controller has several available actions (which are just .NET methods). According to the request, the appropriate action will be executed and will be responsible for calling the involved business process (retrieving or manipulating the data, in other words, interacting with the model) and return the result to the user (e.g. the HTTP response). The result could be data in a specific format (XML, JSON, ...) but is typically an HTML page, this is the view.

Action oriented

As opposite to the page oriented nature of ASP.NET WebForms, ASP.NET MVC is actions oriented. It means that a URL requested by the user will execute an action of a specific controller rather than getting a physical page file.

Benefits

• The actions oriented nature of MVC is, according to me, a way to stick much more to the request/response context of HTTP because an HTTP request is then really a request to the server and not just a file that is simply returned.
• An action is generally a relatively small piece of code, which is much more maintainable and easy to identify (during bug fixing for instance) than a page with dozens of methods and event handlers in it.

Drawbacks

• ASP.NET MVC is very structured and the structure must be rigorously respected which means it can require a bit more effort to have something functionnal

Conventions based

ASP.NET MVC is based on a series of conventions such as naming. Controllers classes should be in a Controllers directory and each controller class should be named SomethingController with the -Controller suffix. The views should be located in a folder with the controller name and this folder should be located in the Views directory. The URL for an action will look like this: http://mysite/Test/MyAction for calling the action MyAction of the controller TestController. ASP.NET MVC propose a route handling system that allow to map some URL pattern to the appropriates controllers and actions.

Benefits

• The structure of the application and the project is very well defined, and will be very easy to maintain or upgrade.

Drawbacks

• Again, the developer will have to be much more rigorous to respect all the conventions

Razor View Engine

A view engine is a component responsible for rendering a view according to some context and model, until ASP.NET MVC 3, the default view engine was classical ASPX page with which the developer had to write some ASPX code and had the possibility to use classical ASPX components and controls. With ASP.NET MVC 4 came a new default view engine, Razor. It is much closer to the standard HTML. The developer has to write some .cshtml (or .vbhtml) files that contains regular HTML only (no custom tags such as <asp:TextBox /> ...) and has the possibility to write some C# or VB.NET code for dynamic content. By the way, WebForms view engine is still available for developers who still want to use it.

Benefits

• The developer will know more accurately at development time what will be contained in the HTML result.
• The extra generated code will be minimal
• There will not be such things as generated so so long and unidentifiable IDs for html elements
• Globally, the developer regain the control of the final output

Drawbacks

• Developers that are used to WebForms controls and do not know much about standard HTML could be a bit lost
• There are no controls such as in WebForms context and everything must be regular HTML

Extensibility and customization

Each single and tiniest component of ASP.NET MVC could be customized or overridden (Controller Factories, HTTP Handler, Route Handler, Action Filters, View Engine, ...). It is an easy way for a developers team to create their own framework and ASP.NET overset.

Benefits

• Developers could take the full control of their application from end to end
• By customizing things, the developers could be much more aware of what is really happening in the mechanisms of ASP.NET
• Basically every requirement could be fullfilled with the etensible nature of ASP.NET

Drawbacks

• How could it be a drawback here? Who can do more can do less! ;)

My thoughts and experience

Well, You probably got it! I obviously prefer ASP.NET MVC! Why? Because, real web developers with real skills and knowledge of the technologies will be able to develop an app with MVC. They will know exactly what is happening in their application and know how it works and why it works like this. A good developer should design his application thinking forward about maintenance, upgrade and reusability of his components and not just "get it work!". Unfortunately, it is too easy to go that way with WebForms, and it is my main criticism about it. A few times ago, someone told me "A boar can not jump high and far at the same time", this is true, an application cannot last a long time if it is not designed to do so. Let's share your opinions and experiences about this topic !  

Hope to read you soon,

Kind regards,

Yannick