Architectural differences between WebForm and MVC in ASP.

ASP. Webform (behind code)

There are 5 problems with this behind code pattern, and we use MVC's design ideas to solve these problems separately.

1. View-based scenarios to address behavior-based requirements

As you can see, the entire request process looks strange:

• The user initiates an HTTP request, such as an HTTP Post/get
• The IIS server maps the request to the view
• The view invokes the life cycle of the page and, through event-driven, invokes the appropriate interaction method
• Finally show the result of the interaction to the end user

Since Microsoft chose a view-based design from the outset, it is difficult for the architecture itself to move closer to design ideas based on user interaction. In other words, when a user makes a "buy" request, it first accesses the view page "Shopping.aspx", the background logic code in "Shopping.aspx.cs", the page life cycle will return the results of the page to the user.

If the idea of using MVC is based on user interaction, then the process will be as follows:

2. Side effects of bad architecture--tight coupling

Simply put, it's hard to simply peel off Customer.aspx.cs and customerdetailed.aspx, and the backend code is tightly tied together and hard to reuse. If we can get the request through action first, and the data from the different view view,action is determined by the controller which view to display, then the request process will be this:

So we can easily control whether the end result is a mobile page display or a normal page display, as follows:

 public  actionresult Index (string  Span style= "color: #000000;" > DeviceType) { if  (ViewType =  "mobile    { return  View ( "mobileview              );  else   {
       return  View ( normalview   ); }}

3, HTML is not the only return type

The default return type is fixed, and all are HTML types, because the view and background code behind codes are tightly coupled. If you want to change the type, you must set Content-type and call the Response.End method.

If we create an action, the returned type is specified by the action and the system can output different return types in the same action depending on the conditions. The code is as follows:

 public  actionresult Index (string  Span style= "color: #000000;" > ViewType) { if  (ViewType =  " json   "  return  Json (new   Customer (), jsonrequestbehavior.allowget);  else   {
     return  View ( displaycustomer  , new   Customer ()); }}

4. Flexible combination of views and data

WebForm is a view-first schema, so the view determines the data that is presented, so the view is very extensible, and if you encounter a complex data structure, this approach becomes inadequate.

But if it is a behavior-first architecture, when we trigger an action, the action can select different data models and view structures based on different requests, such as:

In MVC, you can select the same data model in different views, such as the following code, where the CustomerData data can be bound either in the Detailcustomer view or in the customer view.

 PublicActionResult Index (stringViewname,customer CustomerData) {            if(ViewName = ="detailed")            {returnView ("Detailcustomer", CustomerData); }            Else            {                returnView ("Customer", CustomerData); }}

This is very cumbersome to implement in WebForm.

5, the behind code as a common class for unit testing

Behind code daemon is a very large class in WebForm and cannot be instantiated easily. To know that WebForm is inherited from the page class, the page class cannot be instantiated directly because it has too many dependencies.

So switch the WebForm schema to the MVC schema, such as:

• Transfer the code in behind to the Controller class and convert the original method to the action method.
• The middle tier is replaced with a data model and a logical interface.
• View views are used only to show data and page layouts.
• There is no change in the DAL layer and other layers because it has little to do with behind code.

In the MVC architecture, a user's request is divided into the following 3 steps:

• When an end user sends a request, the router routes the request to the appropriate controller,controller, which is a collection of logical entities and action actions.
• The controller maps the request to a specific action.
• The action has two tasks, the first is to get the right data, and the second is to bind the data and view views together. The action creates the data model and connects the data model to the specified view, outputting the final corresponding result.

This information is collected from the Internet, make a note, convenient for later inquiries.

Architectural differences between WebForm and MVC in ASP.