Over the years, people have been asking the ASP.NET support team for the ability to develop web applications using a model-view-controller (MVC) architecture. In October 2007, Scott Guthrie presented the first preview of the ASP.NET MVC framework. Ever since, the interest in this product has been growing, and a vast amount of example applications, components, and so on have been released on the Internet by enthusiast bloggers and Microsoft employees.
This chapter describes the MVC pattern and explains the reason why Microsoft started the ASP.NET MVC framework project. It also compares ASP.NET MVC with ASP.NET Webforms and provides guidance on choosing between the two approaches for professional web development.
You will learn the following in this chapter:
What the model-view-controller pattern is, why it exists, and what its advantages are
How the model-view-controller pattern is implemented in the ASP.NET MVC framework
What the driving goals behind the ASP.NET MVC framework are
How the ASP.NET MVC framework compares with ASP.NET Webforms
How to choose between the two alternatives for ASP.NET web development
Model-view-controller, or MVC in short, is a design pattern used in software engineering. The main purpose of this design pattern is to isolate business logic from the user interface, in order to focus on better maintainability, testability, and a cleaner structure to the application. The MVC pattern consists of three key parts: the model, the controller, and the view.
The model consists of some encapsulated data along with its processing logic, and is isolated from the manipulation logic, which is encapsulated in the controller. The presentation logic is located in the view component.
The model object knows all of the data that needs to be displayed. It can also define some operations that manipulate this encapsulated data. It knows absolutely nothing about the graphical user interface—it has no clue about how to display data or respond to actions that occur in the GUI. An example of a model would be a calculator. A calculator contains data (a numeric value), some methods to manipulate this data (add, subtract, multiply, and divide), and a method to retrieve the current value from this model.
The view object refers to the model. It uses read-only methods of the model to query and retrieve data. It can look like an HTML page, a Windows GUI, or even the LED display of a physical calculator. In our example of the calculator, the view is the display of the calculator, which receives model data (the current calculation result) from the controller.
The controller object is the interaction glue of the model and the view. It knows that the model expects actions such as add, subtract, multiply, and divide, and also knows that the GUI will send some events that may require these operations to be called. In the calculator example, clicking on the "+" button on the view will trigger the controller to call the add method on the model and re-render the view with the data updated if necessary.
Applications are commonly split into three separate layers: presentation, business logic, and data access. These layers typically share a set of domain objects, which represent all of the entities that the application can work with. The MVC design pattern fits into the presentation layer, where it handles a user's interaction (controller) with a specific model through a view. Any application can be built using the MVC design pattern, be it a Winforms application, web, PDA, or other such things. The ASP.NET MVC framework, however, focuses on web applications, where the view is rendered as HTML—the controller sits on the web server and communicates with the business layer using the domain model. The business layer communicates with the data abstraction layer, also using the domain model as a shared set of entities that are passed around in the application logic. The schematic overview of an application layer structure based on the MVC pattern can be seen in the following figure:
Model-view-controller, or MVC in short, is a design pattern used in software engineering. The main purpose of this design pattern is to isolate business logic from the user interface, in order to focus on better maintainability, testability, and a cleaner structure to the application. The MVC pattern consists of three key parts: the model, the controller, and the view.
The model consists of some encapsulated data along with its processing logic, and is isolated from the manipulation logic, which is encapsulated in the controller. The presentation logic is located in the view component.
The model object knows all of the data that needs to be displayed. It can also define some operations that manipulate this encapsulated data. It knows absolutely nothing about the graphical user interface—it has no clue about how to display data or respond to actions that occur in the GUI. An example of a model would be a calculator. A calculator contains data (a numeric value), some methods to manipulate this data (add, subtract, multiply, and divide), and a method to retrieve the current value from this model.
The view object refers to the model. It uses read-only methods of the model to query and retrieve data. It can look like an HTML page, a Windows GUI, or even the LED display of a physical calculator. In our example of the calculator, the view is the display of the calculator, which receives model data (the current calculation result) from the controller.
The controller object is the interaction glue of the model and the view. It knows that the model expects actions such as add, subtract, multiply, and divide, and also knows that the GUI will send some events that may require these operations to be called. In the calculator example, clicking on the "+" button on the view will trigger the controller to call the add method on the model and re-render the view with the data updated if necessary.
Applications are commonly split into three separate layers: presentation, business logic, and data access. These layers typically share a set of domain objects, which represent all of the entities that the application can work with. The MVC design pattern fits into the presentation layer, where it handles a user's interaction (controller) with a specific model through a view. Any application can be built using the MVC design pattern, be it a Winforms application, web, PDA, or other such things. The ASP.NET MVC framework, however, focuses on web applications, where the view is rendered as HTML—the controller sits on the web server and communicates with the business layer using the domain model. The business layer communicates with the data abstraction layer, also using the domain model as a shared set of entities that are passed around in the application logic. The schematic overview of an application layer structure based on the MVC pattern can be seen in the following figure:
Being a web developer, you will definitely relate to some, if not all, of the following pains. The first web applications that developers created were executable programs running on a server, which were called Common Gateway Interface (CGI) applications. These CGI programs accepted an HTTP request issued by a user's web browser, and returned HTML responses based on the requested action. One of the difficulties with these kinds of programs is that they are very hard to maintain and scale.
Along with other software companies, Microsoft started creating their own implementation for delivering interactive web applications, Active Server Pages, or ASP, at that time. One disadvantage of ASP was that code and markup were sitting in the same file, making the code very hard to read and maintain, especially for larger projects. Luckily, ASP.NET was introduced a few years later. ASP.NET offered the separation of code and templates, and allowed for easier debugging and rapid application development by using an event-driven model that most desktop developers are familiar with. For example, ASP.NET provides an OnClick
event handler, which is fired after a user clicks on a button, in the same way that Winforms development is done.
At the end of 2007, Microsoft released a first preview of the ASP.NET MVC framework that would break with dependencies on this event-driven model and allow for cleaner separation of model, code, and markup.
Microsoft started building the ASP.NET MVC framework with the following ideas in mind:
Clean separation of concerns, testability, and support for test-driven development (TDD) by default. The framework provides interface-based and thus easily mockable core contracts. Unit tests are not required to be run inside an ASP.NET process, making unit testing fast and independent of a specific unit test framework (NUnit, MS Test, xUnit, and so on). In ASP.NET Webforms, testing could be done only after deploying an application and database on a server and firing automated macros on the user interface. In ASP.NET MVC, every action that a user can perform can be unit tested automatically, without requiring the deployment of the application.
A highly extensible and pluggable architecture—every component can be easily replaced or customized. This pluggable architecture also allows easier use of the dependency injection design pattern by using frameworks such as Unity, Castle Windsor, Spring.net, and so on.
It includes a powerful URL routing component that enables you to build applications with clean, search engine friendly URLs. For example, the URL
/employees/show/123
could be easily mapped to theShow
action method of theEmployeesController
class for employee number123
.Existing ASP.NET features are still available: master pages, content pages, user controls, sessions, membership, and so on. The only difference is that there's no ViewState or page life cycle involved.
Full control of your HTML markup. The ASP.NET MVC framework does not inject extraneous HTML code into your rendered page, unlike ASP.NET Webforms, which injects ViewState, resources, and so on.
The MVC pattern helps you to create applications that have a clean separation of concerns. Separation of concerns specifies where each type of logic should be located in the application. This helps you to manage complexity and scalability when building an application. As the application is divided into different modules (data, interaction, user interface, and so on), it becomes easier to maintain and test. The separation of all of the components also allows for parallel development: one developer can work on the model, another one on the controller, and a web designer can focus on creating the view. Using the ASP.NET framework enables you to make extensive use of the advantages that the MVC pattern offers.
Note
Aside from using the model-view-controller pattern provided in the ASP.NET MVC framework, the Microsoft Patterns & Practices Team provides the Web Client Software Factory (WCSF) to help implement the model-view-presenter (MVP) design pattern in your applications.
The MVC and MVP patterns are comparable, but differ in certain aspects. The view in MVC knows about the model, whereas the view in MVP does not. In MVC, the view is responsible for how model data is represented, whereas in the MVP pattern, the presenter sets data in the view.
Another difference between both patterns is that in the MVC pattern, there are multiple controllers, whereas presenters in the MVP pattern are usually responsible for all of the page flows regarding a certain subject. For example, the MVC pattern might have a PricingController
and a CustomerController
, whereas in the MVP pattern, these can be grouped in a SalesPresenter
.
Refer to the following URL for more information on the differences between ASP.NET MVC and WCSF: http://blogs.msdn.com/simonince/archive/2007/11/22/the-asp-net-mvc-framework-using-the-wcsf-as-a-yardstick.aspx
You should know that the ASP.NET MVC framework is not a replacement for ASP.NET Webforms—it's an alternative that you can choose if it is well-suited for a specific situation. Make sure that you weigh and compare the advantages of each solution prior to picking a specific direction.
The ASP.NET MVC framework offers the following advantages:
Complexity of application logic is made easier to manage because of the separation of an application into model, view, and controller.
It allows for easier parallel development; each developer can work on a separate component of the MVC pattern.
It provides good support for TDD, mocking, and unit testing frameworks. TDD enables you to write tests for an application first, after which the application logic is developed. TDD, mocking, and unit testing are explained in Chapter 9, Testing an Application.
It does not use ViewState or server-based forms, which allows you to have full control over the application's behavior and HTML markup.
It uses RESTful interfaces for URLs, which is better for SEO (Search Engine Optimization). REST is short for REpresentational State Transfer—the concept of using URLs as the link to a resource, which can be a controller action method, rather than to physical files on the web server.
A typical page size is small, because no unnecessary data is transferred in the form of hidden ViewState data.
It integrates easily with client-side JavaScript frameworks such as jQuery or ExtJS.
ASP.NET Webforms offers the following advantages:
It offers an event model over HTTP that is familiar to any developer. This event model also benefits the creation of business web applications.
It provides a lot of controls that are familiar to any developer—data components such as data grids and lists, validation controls, and so on. These components are highly integrated in the development environment.
There are numerous third-party control vendors that can deliver almost any possible control.
Being familiar to developers allows ASP.NET Webforms to facilitate rapid application development.
Functionality is concentrated per page. It uses ViewState and server-based forms, which makes state management easier.
In general, choosing between ASP.NET MVC and ASP.NET can be based on the following five criteria:
1. Are you considering test-driven development (TDD)?
TDD enables you to write tests for an application first, after which the application logic is developed. An ASP.NET Webforms application uses only one class to display output and handle user input. Automated testing of this class is complex as you are required to load the full ASP.NET stack into a separate process (for example, in IIS). The MVC framework allows the testing of each component separately, without requiring the full ASP.NET stack. For example, you can test your model separately from your controller without requiring a view. If you are considering TDD, the ASP.NET MVC framework will be the better choice.
2. Is there a need for fine control over HTML markup?
ASP.NET Webforms automatically inserts hidden HTML markup, IDs, JavaScript, and so on, into your page's HTML output because of its event‑driven architecture and its use of ViewState. The ASP.NET MVC framework allows for 100% control over the HTML output. If you require full control over your HTML markup, the ASP.NET MVC framework will be the better choice.
3. Is the application heavily data-driven?
If you are developing an application that is heavily data-driven and is using grids or a lot of master-detail editing of data, ASP.NET Webforms may be the better choice as it provides a lot of controls that will aid you in the development of these kind of applications. Of course, you can use the ASP.NET MVC framework for these tasks too, but you will be required to write more code to achieve the same goal.
4. Is there a need for a Winforms-like development approach?
Does your development team write Winforms code? Is there a need for an event-driven programming approach? In these cases, consider ASP.NET Webforms in favor of ASP.NET MVC.
5. Is there a need for a rapid application development (RAD) development approach?
Does your client expect a quick prototype of an application? Is the use of drag-and-drop development using pre-created web controls required? If so, consider ASP.NET Webforms in favor of ASP.NET MVC.
In this chapter, we have learned what the model-view-controller pattern is, why it is there, and what its advantages are. We also have seen how this pattern is the base for the ASP.NET MVC framework and what the driving goals behind the ASP.NET MVC framework are.
Another thing that we have seen is how the ASP.NET MVC framework compares with ASP.NET Webforms, and also how to choose between the two alternatives in ASP.NET web development.