The discussions on webform and MVC have been discussed for a long time at the beginning of the year. I have no intention to argue Which architecture model is more suitable for our development. No matter which field, the existence of technology has different historical significance and market value. I pay more attention to finding the most convenient way to do things at the current stage from the technical implementation perspective by mastering more technologies at the right opportunity. So please note that the advantages and disadvantages of webform and MVC are not discussed here. Applicable scenarios. Only ASP. net webform and ASP. net MVC, also belongs to ASP. the two different web development technologies under the. NET Framework give full play to ASP. the powerful functions of the net platform and the ability to master ASP. net webform developers switch to ASP. net MVC Architecture learning cost. This is my articleArticleAt the same time, I also hope to provide some comments and foreshadowing for my subsequent MVC series of articles.
Previously, I was engaged in ASP. NET development. Without special instructions, it refers to ASP. NET webform development. In the past, the development of ASP. NET technology was directly reflected in the progress of webform technology. After the emergence of ASP. net mvc, the ASP. NET technology we have mastered is still effective for ASP. net mvc and is the most basic part. Including page processing flow, Web Request context object, Web configuration system, public component module, and some server controls. I want to elaborate on ASP. NET MVC's inheritance of ASP. NET technology from these blocks:
- page processing process: Asp. net MVC page processing flow is still in ASP. net original processing flow extension, under the premise that the upstream request channel remains unchanged, through the specific ihttpmodule and ihttphandler to process ASP.. Net MVC request. Unlike webform page processing, in webform, each page is an ihttphandler instance. The page event process starts with the ihttphandler processrequest (httpcontext) method. In ASP. net mvc, All controllers are not inherited instances of ihttphandler, and their actions are executed in mvchandler. Of course, we can also customize mvchandler.
- Web Request context object: in ASP. net mvc, the thread model for processing requests has not changed. The request context object is still shared with the original ASP. NET webform.
- Web configuration system: Asp.. Net MVC still uses the original configuration system. only some configuration nodes in config are not applicable to ASP. net MVC, such as page Access Authorization configuration.
- Public component modules: in ASP. net mvc, built-in and custom component modules, including membership, healthmonitoring, httpmodule, and trace, are still available.
- some server controls are available: First, we use the. ASPX page as the MVC view. Although the suffix is still. aspx, it is no longer an executable page file or an ihttphandler in a pure sense. However, it still inherits from the original base page class. In ASP. in. Net MVC, it is displayed as a view, and the page is still executed using processrequest as the entry, which means that the events and functions related to the Event Callback will not be executed, the execution event process on the page is still valid. In this case, if we do not consider the performance of server controls and other factors, we can still use most of the server controls, of course, it does not depend on you.
The above are some of my summary ASP. net MVC for ASP. net, but as an ASP. NET technology development, there are a lot of things in itself is not good, don't say, it should also know that. However, it is more helpful to distinguish ASP. NET, (ASP. NET) webform, ASP. net mvc (why ASP. NET in front of webform is added with arc? Let's talk about the reasons.) the conceptual differences and relationships between the three are as follows.
Below I would like to talk about the obvious differences between ASP. NET MVC and the previous ASP. NET (webform) Development Technology in practice:
- The. aspx file is no longer a page that can be independently requested. You cannot perform physical permission control on it.
- We have fewer server controls. We can still use it. You can ignore the performance impact of runat = 'server. However, it is not guaranteed that all server controls are available. There may be other reasons for you to choose not to use the server control.
- We do not have the PostBack and page sending events mechanisms. When submitting a form, we basically use the native web method, and the amount of data transmitted is more reasonable.
- We use less viewstate. It is useless, which means we can still use it. Because of the limitations of the MVC Architecture, the value stored in viewstate is not serialized to the client. Its validity is in the context of a request. In some specific scenarios, viewstate can still exert its residual heat without affecting its performance.
- To process a user-defined request, such as an RSS request. We no longer need to define an ihttphandler or a specific. ASPX page. Each request is processed only in the Action Function of the controller. In the action function, you can output view and JSON string, you can also output files and output streams in any custom format.
- Business logic and UI logic are well separated from the architecture, but it is still effective if you do not want to do so. In this case, select webform.
the unification of ASP. net mvc and webform in many implementations ensures that developers who have mastered the original development mode of ASP. NET can get started with MVC smoothly. I will discuss several articles about MVC after I use MVC to practice my own website.