ASP.NET MVC is a free and fully supported framework for building web applications that use the model-view-controller pattern. Like ASP.NET Web Forms, ASP.NET MVC is built on top of the ASP.NET Framework. This means you can use in ASP.NET MVC applications the same APIs for security, state management, membership, caching, and so on that you could use in traditional ASP.NET Web Forms applications.
In the ASP.NET MVC world, many improvements to ASP.NET have been included in the framework itself. The main purpose of this design pattern is to isolate business logic from the user interface in order to focus on better maintainability, improved testability, and a cleaner structure to the application.
Every ASP.NET MVC application has three core parts: a model, views, and controllers. In short, the model consists of all the classes that handle data and business logic. Data processing using model classes is initiated by the controllers that are in charge of user requests. Once the data processing is complete the controller creates a response to the user by sending the results to a View who then produces HTML to be rendered in the browser.
The MVC Pattern
Figure 1-2 illustrates a simple implementation of the MVC pattern. The straight arrows indicate direct associations while the curved arrows identify indirect associations.
Figure 1-2. Model-view-controller implementation
The model in the MVC pattern represents the parts of the application that implement the data domain logic. The operation of the model might come from the generation of classes representing objects in a data store such as a database (for example, Entity Framework data classes).
Views are the visible elements in the application. They are the components that typically show users data from the model. A view page typically receives a view model object from the controller (the view doesn’t care how this data was obtained—that’s the controller’s responsibility!). The view page contains HTML (and possibly some UI-related code) to determine how to render the model data back to the browser.
The controllers are classes that collect the user requests, work with the model, and ultimately select a view to render the appropriate UI.
When to Use ASP.NET MVC
ASP.NET MVC has certain capabilities that make it the best option to choose if you need one or more of the following:
• A high level of control over the generated HTML: Unlike Web Forms, Views in ASP.NET MVC render HTML exactly as you tell them to. Recently, Web Forms have been improved in this area but still don’t have the level of control MVC has.
• Easier unit testing: With ASP.NET MVC, it is very easy to follow testing patterns such as test-driven development (TDD). Because of the complex event lifecycle in Web Forms, on top of a control-based framework, TDD is a lot easier with MVC.
• Separation of concerns: This refers to having all aspects of the system clearly separated from one another. Because of the pattern it implements, an MVC application is divided into discrete and loosely bound parts (model, views, and controllers), which makes it easy to maintain.
ASP.NET MVC Benefits
Compared to Web Forms, ASP.NET MVC applications benefit by including all ASP.NET core features but also by the features in the MVC pattern. Some of those benefits are:
• The MVC pattern itself makes it easier t • o manage complexity by clearly separating the functionality of the application into three core parts, the model, the view, and the controller.
• ASP.NET MVC web applications do not use view state or server-based forms. This makes the MVC framework ideal for developers who want full control over the behavior of an application. View state can become very large, which is a problem for devices like smartphones running over slow networks (transmitting all that information can be very slow). In a Web Forms page, you could only have one <form> per page. This is quite a major restriction. In MVC, there is no such restriction—that is, you can have as many<form> elements as you like.
• ASP.NET MVC provides better support for test-driven development (TDD).
• ASP.NET MVC works well for web applications that are supported by large teams of developers and for web designers who need a high degree of control over the HTML.
ASP.NET MVC Request Processing
One of the most important concepts to understand about MVC applications is that no relationship exists between a page request and a physical file inside the web server. In a traditional Web Forms and Web Pages application, every page request is translated into a call to a physical file in the webserver. For example, if your request is something like http://myapp/mypage.aspx, the web server interprets the request by looking at the root of the website for a file named mypage.aspx.It then processes the file and returns the generated HTML.
In the case of an MVC application, when you make a request (e.g.,http://myapp/product/list), a component called routing engine matches the request to a specific route. A route defines requests using a pattern string and establishes the controller and method in the controller class that should process the request. Once the route is
identified, the routing engine creates a request handler that in turn will create the controller object that will process the request (in our example, the controller is “product”). The controller then invokes the method in the controller class that will process the request (in the example is named “list”). These methods in controller classes that process requests are called action methods. When the processing of the request ends, the action method produces a result to
send back to the user. Normally the result is some HTML (rendered by a View) the user will see in the browser.
We will examine the routing engine in more detail in Chapter 10. Figure 1-3 illustrates the entire server-side processing life cycle in an ASP.NET MVC web application.
Figure 1-3. ASP.NET MVC request process
--------------------------------------------------------------------------------------
A LITTLE ASP.NET MVC HISTORY
--------------------------------------------------------------------------------------
The first version of ASP.NET MVC, released on March 13, 2009, was a full-featured implementation of the MVC pattern built on top of ASP.NET. This version included features such as a routing engine, helper methods to create HTML and AJAX elements in pages, data binding, the Web Forms view engine, and more.
ASP.NET MVC 2 debuted in March 2010 and added even more features, including a rich set of UI helpers for automatic scaffolding; customizable templates; strongly typed HTML helper methods; asynchronous controllers; the concept of areas, allowing the separation of large applications into different projects; attribute-based model
validation in the client and the server; and better tools in Visual Studio.
Less than a year later (10 months to be precise), Microsoft released ASP.NET MVC 3, which introduced a whole bunch of new features, including .NET 4 data annotations and a new view engine (Razor). JavaScript got its own improvements with unobtrusive JavaScript, jQuery validation, and JSON binding.
Slowing down the pace a bit, ASP.NET MVC 4 shipped on August 15, 2012 (19 months after version 3) and was included in Visual Studio 2012 when it shipped in September of the same year.
--------------------------------------------------------------------------------------
ASP.NET MVC 4 Features
ASP.NET MVC 4 is built on top of the many features of its previous versions and include new features like:
• ASP.NET Web API, a new framework for building HTTP and RESTful services.
• A new HTML5-based default template in Visual Studio and a new Mobile Application project template.
• Automatic selection of rendered views with Display Modes. This is particularly useful when building applications that will run not only on desktop browsers but on mobile browsers as well. It will let the application determine the best view to render based on the browser making
the request.
• jQuery Mobile and mobile features.
• Task support for asynchronous controllers.
• Microsoft Windows Azure SDK support for deploying ASP.NET MVC 4 applications to Windows Azure.
• Bundling and minification for CSS and JavaScript files to help reduce the amount of HTTP requests as well as the size of those requests.
• Facebook, OpenID, and OAuth authentication.
In the ASP.NET MVC world, many improvements to ASP.NET have been included in the framework itself. The main purpose of this design pattern is to isolate business logic from the user interface in order to focus on better maintainability, improved testability, and a cleaner structure to the application.
Every ASP.NET MVC application has three core parts: a model, views, and controllers. In short, the model consists of all the classes that handle data and business logic. Data processing using model classes is initiated by the controllers that are in charge of user requests. Once the data processing is complete the controller creates a response to the user by sending the results to a View who then produces HTML to be rendered in the browser.
The MVC Pattern
Figure 1-2 illustrates a simple implementation of the MVC pattern. The straight arrows indicate direct associations while the curved arrows identify indirect associations.
Figure 1-2. Model-view-controller implementation
The model in the MVC pattern represents the parts of the application that implement the data domain logic. The operation of the model might come from the generation of classes representing objects in a data store such as a database (for example, Entity Framework data classes).
Views are the visible elements in the application. They are the components that typically show users data from the model. A view page typically receives a view model object from the controller (the view doesn’t care how this data was obtained—that’s the controller’s responsibility!). The view page contains HTML (and possibly some UI-related code) to determine how to render the model data back to the browser.
The controllers are classes that collect the user requests, work with the model, and ultimately select a view to render the appropriate UI.
When to Use ASP.NET MVC
ASP.NET MVC has certain capabilities that make it the best option to choose if you need one or more of the following:
• A high level of control over the generated HTML: Unlike Web Forms, Views in ASP.NET MVC render HTML exactly as you tell them to. Recently, Web Forms have been improved in this area but still don’t have the level of control MVC has.
• Easier unit testing: With ASP.NET MVC, it is very easy to follow testing patterns such as test-driven development (TDD). Because of the complex event lifecycle in Web Forms, on top of a control-based framework, TDD is a lot easier with MVC.
• Separation of concerns: This refers to having all aspects of the system clearly separated from one another. Because of the pattern it implements, an MVC application is divided into discrete and loosely bound parts (model, views, and controllers), which makes it easy to maintain.
ASP.NET MVC Benefits
Compared to Web Forms, ASP.NET MVC applications benefit by including all ASP.NET core features but also by the features in the MVC pattern. Some of those benefits are:
• The MVC pattern itself makes it easier t • o manage complexity by clearly separating the functionality of the application into three core parts, the model, the view, and the controller.
• ASP.NET MVC web applications do not use view state or server-based forms. This makes the MVC framework ideal for developers who want full control over the behavior of an application. View state can become very large, which is a problem for devices like smartphones running over slow networks (transmitting all that information can be very slow). In a Web Forms page, you could only have one <form> per page. This is quite a major restriction. In MVC, there is no such restriction—that is, you can have as many<form> elements as you like.
• ASP.NET MVC provides better support for test-driven development (TDD).
• ASP.NET MVC works well for web applications that are supported by large teams of developers and for web designers who need a high degree of control over the HTML.
ASP.NET MVC Request Processing
One of the most important concepts to understand about MVC applications is that no relationship exists between a page request and a physical file inside the web server. In a traditional Web Forms and Web Pages application, every page request is translated into a call to a physical file in the webserver. For example, if your request is something like http://myapp/mypage.aspx, the web server interprets the request by looking at the root of the website for a file named mypage.aspx.It then processes the file and returns the generated HTML.
In the case of an MVC application, when you make a request (e.g.,http://myapp/product/list), a component called routing engine matches the request to a specific route. A route defines requests using a pattern string and establishes the controller and method in the controller class that should process the request. Once the route is
identified, the routing engine creates a request handler that in turn will create the controller object that will process the request (in our example, the controller is “product”). The controller then invokes the method in the controller class that will process the request (in the example is named “list”). These methods in controller classes that process requests are called action methods. When the processing of the request ends, the action method produces a result to
send back to the user. Normally the result is some HTML (rendered by a View) the user will see in the browser.
We will examine the routing engine in more detail in Chapter 10. Figure 1-3 illustrates the entire server-side processing life cycle in an ASP.NET MVC web application.
Figure 1-3. ASP.NET MVC request process
--------------------------------------------------------------------------------------
A LITTLE ASP.NET MVC HISTORY
--------------------------------------------------------------------------------------
The first version of ASP.NET MVC, released on March 13, 2009, was a full-featured implementation of the MVC pattern built on top of ASP.NET. This version included features such as a routing engine, helper methods to create HTML and AJAX elements in pages, data binding, the Web Forms view engine, and more.
ASP.NET MVC 2 debuted in March 2010 and added even more features, including a rich set of UI helpers for automatic scaffolding; customizable templates; strongly typed HTML helper methods; asynchronous controllers; the concept of areas, allowing the separation of large applications into different projects; attribute-based model
validation in the client and the server; and better tools in Visual Studio.
Less than a year later (10 months to be precise), Microsoft released ASP.NET MVC 3, which introduced a whole bunch of new features, including .NET 4 data annotations and a new view engine (Razor). JavaScript got its own improvements with unobtrusive JavaScript, jQuery validation, and JSON binding.
Slowing down the pace a bit, ASP.NET MVC 4 shipped on August 15, 2012 (19 months after version 3) and was included in Visual Studio 2012 when it shipped in September of the same year.
--------------------------------------------------------------------------------------
ASP.NET MVC 4 Features
ASP.NET MVC 4 is built on top of the many features of its previous versions and include new features like:
• ASP.NET Web API, a new framework for building HTTP and RESTful services.
• A new HTML5-based default template in Visual Studio and a new Mobile Application project template.
• Automatic selection of rendered views with Display Modes. This is particularly useful when building applications that will run not only on desktop browsers but on mobile browsers as well. It will let the application determine the best view to render based on the browser making
the request.
• jQuery Mobile and mobile features.
• Task support for asynchronous controllers.
• Microsoft Windows Azure SDK support for deploying ASP.NET MVC 4 applications to Windows Azure.
• Bundling and minification for CSS and JavaScript files to help reduce the amount of HTTP requests as well as the size of those requests.
• Facebook, OpenID, and OAuth authentication.
No comments:
Post a Comment