Home > SKIP > Visual Studio .Net > ASP.Net MVC Patterns

ASP.Net MVC Patterns

Objective: Better re-usability of the code, model independence and intelligence structure for separation of concerns.

Abbreviations and Definitions:

Model View Controller

"Models" in a MVC based application are the components of the application that are responsible for maintaining state. Often this state is persisted inside a database.

"Views" in a MVC based application are the components responsible for displaying the application's user interface. It simply manages the display of information.

"Controllers" in a MVC based application are the components responsible for handling end user interaction, manipulating the model, and ultimately choosing a view to render to display UI.

Approaches:

Take an example where one need to be bind the data in a list on clicking of button, there are different approaches that can be followed to achieve the result. Here they are:

  1. Single Asp.Net page: Simplest and most straight forward approach by including in one file both design and code in aspx page.
  2. Code-Behind Refactoring: Here one can separate the view and Model/Controller. i.e.., aspx page will be termed as view and code behind file will be termed as both model as well as controller. This can be achieved by inserting a property of Codebehind=“test.aspx.vb/cs”
  3. Model-View-Controller Refactoring: To resolve the last issue, you need to further separate the model code from the controller. The view code is identical to the code used in the previous implementation. This can be achieved by writing a class and returning an object such as dataset to the code behind “VB/C#” file.

Implementation

  • The request comes from the client and hits the Controller.
  • The Controller calls the Model in order to perform some "business“ operations.
  • The Model returns the results of the operations back to the Controller.
  • The Controller decides which View needs to be rendered and sends it the data that must be rendered.
  • Finally the View renders the output and sends the response back to the client.

Role of Model:

It passively supplies its services and data to the other layers of the application.
Model is responsible to manipulate the result that the controller gives and responds back with the result to the controller, thus resulting in change of view/views

Role of View:

A view object knows how to display and might allow users to edit the data from the application’s model. The view should not be responsible for storing the data it is displaying (Note: This does not mean the view never actually stores data it’s displaying, of course. A view can cache data or do similar tricks for performance reasons)

A view should ensure it is displaying the model correctly. (Example: DataGrid, drop down list or any control which displays the information that was generated by model)

Role of Controller:

A controller object acts as the intermediary between the application's view objects and its model objects. Controllers are often in charge of making sure the views have access to the model objects they need to display.

Example: When users enter a value or indicate a choice through a view object, that value or choice is communicated to a controller object. The controller object might interpret the user input in some application-specific way and then either may tell a model object what to do with this input like "Add a new value" or "Delete the current record".

Based on this same user input, some controller objects might also tell a view object to change an aspect of its appearance or behavior, such as disabling a button.

Advantages:

  • Clear separation of duties and concerns.
  • Testability - support for Test-Driven Development (In 2008, Can be created unit testing methods called NUNIT testing)
  • Fine-grained control over HTML and JavaScript
  • More Control over URLs
  • Reduced code duplication.
  • Better re-usability
  • Optimizing opportunities

ASP.NET MVC is an alternative, not a replacement for an existing form-based approach.

Comparisons

  • First, Form based approach (FBA) is event based: it can be good or bad depending on how you look at it. Good because it helps VB6 and WinForms developers to smoothly migrate their skills to the web application development. Bad because there are dozens of events that are raised during the page life-cycle, and it's not trivial to understand where to put your code. Also because the process logic is tightly coupled with the page life-cycle, it is difficult to test using automated tests.
  • FBA also uses server forms and View State, again, as with the event based model, it can be good since this hides to the developer all the problems related to maintaining the state of the page (values of textboxes, contents of dropdowns and so on), but can also be bad if you want to control exactly how the page is rendered, and you don't need to maintain all the state.
  • MVC reduces code duplication, but maintenance cost will be more.
  • Furthermore, FBA uses server controls: good because they render the HTML for you; bad since they render it the way they want.
  • You can create any application using the systematic approach if it is a small and the one which don't change often. But you should seriously consider the alternative MVC model if your application demands the following:
    • You want to increase parallelism and reduce potential for errors.
    • You want to reuse the database access code on multiple pages.
  • Supports using the existing ASP.NET .ASPX, .ASCX, and .Master markup files as "view templates" (meaning you can easily use existing ASP.NET features like nested master pages, <%= %> snippets, declarative server controls, templates, data-binding, etc).
  • Supports existing ASP.NET features like forms/windows authentication, membership/roles, output and data caching, session/profile state management etc.
  • However in .Net 2008 MVC pattern, it does not use the existing post-back model for interactions back to the server.  Instead, you'll route all end-user interactions to a Controller class instead - which helps ensure clean separation of concerns and testability.

Example of Model, View and Controller:

Take an example where user will add the items from textbox to the list box. The list box items collections can be saved either in a array list collection or some database.

Model consists of the methods that will help to add and remove the item collection to the list box.

Controller will call the methods that are declared in the model with necessary parameters and send the result to the view.

View will displays the data and shows the response message (if any).

References: