Comparison between MVC and WebForm

From: http://www.cnblogs.com/xiaozhi_5638/p/4019065.html

ASP. Webforms Behind Code the benefits and problems that exist

The ASP. NET WebForms is a rad/visual (fast visualization) Web application development technology. That is, the developer simply drags the control onto the form designer, and VS will generate the code in behind code (aspx.cs file, translator note ).

In other words, you can write code in its event handlers after you drag and drop a button in the designer.

The Behind code file is the key to a developer's ability to quickly develop a WebForms program, as it encapsulates the underlying complex technical processes such as event, delegates, HTTP protocol post, GET, session management, and so on. You can read this blog why Microsoft have partial classes (although most of the opponents of this article, but I think there are some reasons, the translator note), understand Microsoft's success in UI design story.

But it's the way behind code works to create 5 serious problems with developing web programs, so let's talk about these 5 questions and how MVC solves them.

problem 1 : Use a "view-based" solution to respond to "behavior-based" requirements

Web sites are ultimately intended for end users, and end users visit a site for a specific purpose, and then they use "behavioral actions" ( such as entering URLs, clicking submit buttons, etc. ) to express what they want. For example, when a person goes to a shopping site for shopping, he will express what he wants by doing the following:

• Buy things
• Print Invoice

These actions are done by typing a URL similar to a click button, right button, or in the browser's address bar. Because of the characteristics of these behaviors, the Web program chooses to use the HTTP protocol because it contains many similar actions, such as post, GET, put, and delete, which can be used to express the intent of the end user in more vivid terms. Naturally, if we were able to map the user's behavior one by one to our program method (function), it would be more meaningful and make the project architecture clearer.

However, Microsoft cannot do so. Because Microsoft has always wanted to promote its "rapid application Development" (RAD) concept (or we can call it "visual programming"), it finally chose a "view-based" solution to respond to "behavior-based" requirements.

As shown, the user's "request process" presents an eccentric route (see).

• End user sends a request by Post/get method
• The IIS server transfers the request to the corresponding view ( page , translator note )
• The view Initializes a page, starts the page life cycle, fires the corresponding event ( such as page.load, translator note ), and ultimately processes the end user's behavior ( in a three-tier architecture, it calls the business logic, Data access layer for processing, translator note )
• The end server response the results to the end user's browser in HTML form

As above, Microsoft has developed a "view-based" architecture scheme to cope with a "behavior-based" requirement. In other words, if an end user makes a "buy" request, then the request is processed by a page similar to "shopping.aspx", then the page then notifies the "Shopping.aspx.cs", then begins a complex page life cycle, Finally, the corresponding event (Page.load,button.click) is fired to request processing and the result is returned to the end user.

The above process is quite complicated, and any request from the end user needs to go through a complex page life cycle before it can actually be processed. So, what about creating a "behavior-oriented" architecture that replaces "view-oriented"?

If we process the request first and then render the view to the end user, does this process have to be clearer? In fact, this is what MVC does, and the user requests to be processed by the corresponding controller before the latter renders the corresponding view (with model).

problem 2 : Bad architectural pattern brings side effects: tight coupling

Once you have chosen an architectural model for the next three excesses, you will eventually have to make compromises in order to adapt to it, resulting in more and more negative results. This is exactly what ASP. NET WebForms. Behind Code (aspx.cs file, translator note ) never really conforms to "loose coupling" rules, such as ASPX.CS files that can never be separated from ASPX files.

In other words, we cannot easily combine "Customer.aspx.cs" and "customerdetailed.aspx" together, Behind code and views are only linked together and cannot be reused.

If you compare the behind code code with the other modules in the project, you will find that the former is not only bulky but also riddled with countless event handler code. This not only makes the code difficult to read, but later maintenance is even more difficult.

If we replace the "view first" schema with the "behavior first" scenario, it is easy to reuse some of the logic code, and the view presented to the end user can be switched at will. For example, if an end user sends a "Display" request, then we can choose to send "displaydesktop.aspx" or "displaymobile.aspx" to the end user, which is entirely dependent on the user currently using the device.

In MVC, we can easily decide whether to show "Mobileview" or "Normalview", and you can imagine how complicated it is to achieve this in WebForms.

problem 3 : HTML is not a unique format for the server to return data

In WebForms, the view and behind code are not only in a "tightly coupled" state, and even the data format returned by the server is fairly fixed, with HTML as the default. If you want to change the format of the returned data, then you have to deal with the Content-type and Response.End methods, which is a headache.

In fact, if we use the "behavior first" scenario, after processing the user request, there is a big chance to decide exactly what format of data to return to the user. The following is an MVC code that determines whether to return JSON or HTML to the user, depending on the parameters passed in. This flexibility is almost impossible to achieve in WebForms.

problem 4 : A flexible combination of "view" and "data", which in fact means MVC The advantages of the translator note )

When we give the user a response, actually contains the view and data two parts (view represents the structure of the page, data represents the page data, the translator note ). WebForms is a "view-first" architectural pattern, so it is difficult to flexibly switch views that are ultimately presented to the user, and the view is also responsible for invoking the code for logical processing, which is completely contrary to the single responsibility Principle (SRP) ( detailed SOLID Five design principles please refer to the blogger's front blog, the translator note ).

If we use the schema pattern of "behavior first", then when the request arrives, it is processed before deciding what views and data to present to the user.

In MVC, when you process a request, you can write the following code. You can combine the same model ( data, translator's note ) with different view. As shown in the following code, you can combine a model (customerdata) with a view (Detailcustomer), or you can combine it with another view (Customer).

This flexibility is very difficult to implement in WebForms, because in WebForms, the request arrives at the view ( page , translator ), and then it decides what processing logic to invoke. The view decided to die at the beginning.

problem 5 : The Behind Code code defined as a generic class facilitates unit testing (in fact, this means MVC The advantages of the translator note)

In WebForms, Behind code codes appear in the form of a partial class, which is quite complex (inherited from the page class) and cannot easily be created as an instance of it. By default, each page inherits from the pages class, and because the page class relies on more dependencies, it is difficult to instantiate a Web Page object ( in this case, the translator's note when it comes to unit testing ).

Now you might ask, why do you instantiate a page class object yourself ? The reason is simple, because I'm going to do the unit test and I'm going to test if the button Button1 's Click event handler (button1_click) executes as I expected.

But the problem is, if you write the test code in the following way, it throws an exception

This makes the unit testing of the UI very difficult:

In MVC, Behind code becomes a simple normal class ( the various classes in theController , the Translator notes ), and creating these instances is not as laborious as it was before.

MVC really is an effective solution to the above problems?

Turning the "View-based" architecture into a "behavior-based" architecture, we need to make the following modifications (see):

• Define the code in the original behind code (aspx.cs file) as a class in the controller in MVC and change the original event handler to a series of regular methods (we can call it action)
• Originally, the "Middle tier (BLL)" In the three-tier architecture became the current model, which was responsible for providing data and some logical processing
• View is only responsible for display, such as the location of page HTML elements, layout, etc.
• The data Access layer (DAL) in the original three-tier architecture does not require much change since behind code seldom deals with it.

So, after using the MVC architecture,

• The end user sends its request to the Web server, which the server routes to the specified controller
• The controller finds a corresponding action to handle
• Now, action has two things to do, first to access the model to get the data, and then pass the acquired data to the appropriate view, and eventually send the view to the end user's browser

The biggest advantage of ASP. WebForms is Rad and visual (fast visual development), and even now it seems so cumbersome and unsightly, but it does allow you to speed up your program development and finish on time (regardless of other consequences, the translator notes ).

In 2000, Microsoft launched the ASP. NET WebForms was the right decision, because at that time it wanted to attract those who are already familiar with VB6, VF, VC and other rapid development technology developers, I think WebForms has achieved its original purpose. Now it's time for us to step up to learn better architecture patterns, such as MVC ( the corresponding ASP. NET MVC, translator note ).

Comparison between MVC and WebForm