Comparison between ASP.NET Web Forms and ASP.NET MVC Development
When facing a decision to choose between ASP.NET Web Forms or ASP.NET MVC it is important to know that neither technology is meant to replace the other. Although ASP.NET MVC was released at a later date, it is not designed to be a successor to ASP.NET Web Forms. When making this decision it is very important that one learns and understands the differences between these two frameworks. Certain applications might be better suited for one, while other applications might fit better with the other. There are pros and cons with both Web Forms and ASP.NET MVC, and the following page and accompanying demo should reveal some from both camps.
For Microsoft’s point of view on the subject, please refer to this MSDN Magazine article.
|WebForms ||MVC |
|Ease of use ||Separation of concerns |
|ScriptManager/UpdatePanel * ||Ease of testability |
|State Tracking * ||No ViewState, no page life cycle |
|Maturity ||Total control over HTML |
|Control life cycle ||Controller to Model to View |
|Strong 3rd party component market ||Accessibility |
* In discussions that are pro-MVC these can be seen as negatives as well.
Although this is more of a myth than reality, for a long time the lack of ASP.NET MVC developer productivity tools has also been considered a disadvantage for choosing the platform. For example Telerik released a suite built from the ground up according to the principles of ASP.NET MVC as soon as the framework was released by Microsoft. Telerik now offers both an ASP.NET AJAX and ASP.NET MVC UI component suites to give developers more options when choosing the technology for their applications. RadControls for ASP.NET AJAX offers more than 70 high-performing, rich UI controls, and the Kendo UI for ASP.NET MVC offers more than 40 lightweight, HTML5-powered extensions for building rich cross-platform web, data visualization and mobile applications.
ASP.NET AJAX vs ASP.NET MVC – Projects
A WebForm file always has an associated code-behind file, as can be seen in figure 1.2. These code-behind files are actually tightly coupled with the markup of the .aspx file. Server-side controls on the WebForm can actually be referenced directly in the code-behind, and all associated C# or VB.NET code for the markup can usually be found in the code-behind file.
WebForms are also event driven, which means that events such as mouse clicks trigger events which are then handled in the code-behind of the page from which the event was triggered.
In order for a WebForm to be able to take use of AJAX calls, which allows for only specified portions of a page to update, they need to include a ScriptManager control. This control manages all of the client script for AJAX-enabled web pages, and is required on a page that wants to take use of the ASP.NET AJAX framework.
One of the major controls that works hand-in-hand with the ScriptManager is the UpdatePanel. This control allows for partial updates of a page, where only a specific section of a page becomes updated while the other sections remain static. Placing an UpdatePanel on a page and wrapping it around other server-side controls will allow for these controls to be updated only when requested, and not every single time the page posts back.
Both pages and controls in WebForms have life cycles. A life cycle is a series of events that are triggered as the page or control is being loaded. These steps involve initialization, loading, postback event handling, rendering and unloading. Many of these events are executed on every page load, whether it be the initial load of the page or a postback of the same page.
When looking over the rendered HTML from a WebForms application it can be quite difficult to navigate through. Although for simple scenarios the HTML might not be too hard to look through and understand, the more complex the page the more complex the rendered result often becomes. Session state, one of the ways that ASP.NET AJAX handles the session-less nature of the internet, also tends to tag along with the rendered HTML, causing even more cryptic information to be sent along with the HTML. This can often lead to bloated pages, as there is a lot of extra HTML being sent over the wire and rendered on the page.
Views are not tightly coupled with a code-behind, instead they have an associated controller.
Another observation is that the data-related items are found in the Models folder. When a page is loaded the user interacts with the View, and any subsequent actions that are taken are handled in the controllers and models, instead of directly within the View. This allows for a separation of concerns which leads to reduced complexity in architectural design, as well as increase flexibility, maintainability and testability of code.
As mentioned previously, MVC stands for Model-View-Controller. Models are the parts of the application that contains all of the logic for the applications data domain. This usually entails accessing information from a database, work with the data, and then save it back into the database. Views are in charge of displaying the applications user interface. The UI can of course have various functionalities, but generally it is tied to the Model data by, for example, having a Grid displaying data found in a DataTable in the database.
Finally, Controllers are the part of the application that actually works with the model, handles user interaction and selects the particular view to be rendered for the user. While the View displays the information, the Controller actually takes care of the user input and interaction. One of the main advantages with ASP.NET MVC is the clean HTML output that is generated by the Views. Stepping through the source of the page is a lot easier than with the WebForms equivalent, not only for the individual looking over the page but also their browser. Session and ViewState are also not included as part of the HTML, so the final page cleaner and it also has less information stored in it.
ASP.NET AJAX vs ASP.NET MVC – Demo Application
In the demo application there are a couple of demos highlighting some of the main differences between using the Telerik RadControls for ASP.NET AJAX and the Telerik Extensions for ASP.NET MVC. The components that are highlighted are the Menu, TreeView, Editor and Grid.
Download Source Code
The Basics Demo
The first demo simply shows a common scenario where a button is used to update a label. In the ASP.NET AJAX case we take use of an UpdatePanel which wraps the label and the button. The button has a click event which is subscribed to and in the code-behind the label is references and its Text property is modified.
Taking a look at the ASP.NET MVC equivalent we see that the controller, via an ActionResult, is in charge of updating the label’s content. A dynamic variable found in MVC 3’s ViewBag (ViewData for MVC 2 can be used) is used to bind to the label, and any changes to this variable will be reflected in the label.
Site Navigation Demo
Both the RadMenu for ASP.NET AJAX and the Menu for ASP.NET MVC have a similar simple structure. The Menus themselves have an item collection which defines the root items of the Menu. Each one of the Menu items can in turn have its own item collection, which is seen as the sub-items of that particular item.
Content Editing Demo
The RadEditor for ASP.NET AJAX has two possible approaches when configuring what tools should be included with the control. You can, as seen in the demo, define the tools collection declaratively in the markup of the Editor by creating various tool groups and defining tools within them. The other implementation is to use a ToolsFile.xml file which can be used to define the tools to be used outside of the markup of the RadEditor.
The Editor for ASP.NET MVC approaches the tools configuration similarly as the first implementation above. There is a tools collection which takes use of the fluent-API of the Telerik Extensions which allows you to chain several tools that can be used with the Editor.
Data Binding/Editing Demo
The RadGrid for ASP.NET AJAX uses the OnNeedDataSource event when utilizing a more advanced style of binding than just a declarative approach. This event gets fired every time the RadGrid is in need of data (paging, sorting, filtering etc.). Additionally, when manually handling the insert, update and delete operations with the RadGrid one needs to subscribe to either the OnItemCommand event, and use if-statements to find out which operation is occurring, or use the OnInsertCommand, OnUpdateCommand and OnDeleteCommand events.
With the Grid for ASP.NET MVC we simply use the controller to send the data that we need over to our Grid component. We also define the names of ActionResults for each of the CRUD operations, including which controller they are to be found in. One difference between the RadGrid and this Grid is that in the Insert, Update and Delete functions we take use of the GridRouteValues() extension method, which returns route values defining the Grid state. Some of the items included in these route values are current page, sort and filter expressions.