Introduction to ASP. NET 2.0 Internals

Introduction
New features are fun and interesting to learn about, but changes toCore structureOf ASP. NET speak louder to developers who really want to master the technology. In this white paper, we will cover howInternal structureOf ASP. NET 2.0 has changed since version 1. x.
Overview of changes in the core structure from ASP. NET1.0 to ASP. NET2.0

The topics covered in this paper will be of usePerformance-mindedDevelopers andTechnical transaction TSSeeking to fine-tune (adjustment to enable rules) applications. Specifically, we will examine key areas ofCode model,Compilation,Page lifecycle,Extensibility,Performance, AndCaching.
This topic is used by developers and technical architects who focus on performance to adjust the current application. It also focuses on code models, compilation, page survival, scalability, performance, cache, and other aspects.

1. Code Model
   How an ASP. NET Web page is created now
   1. Coding Models in ASP. NET 1.
      Two primary options for developing a Web Form.
      1. Code-inline, Works very well for simple commands. However, for more complex code, writing code-inline results in difficult to read Web pages that mix presentation (HTML) with functionality (code ).
         The code embedded mode is only applicable to simple commands.
      2. Code-behind
         Business logicAndEvent-handling codeCocould be written in a separate, code-only file known as the code-behind file. the code-behind model links a code-only file with the ASPX file that contains presentation tags. by separating the code from the presentation, development teamsCocould work fasterBy allowing the designers to work on the presentation file while the developers worked on the code file.
         Separate the business logic and event handler code from the presentation page
         
   2. The difficulties in 1.x1. x Deficiency
      The primary difficulties with the code-behind model related to the way in which the code-behind file had to be synchronized with the ASPX page. although the ASPX page inherited from the code-behind file in a programming sense, the two files were actually coupled byMore complex relationship.
      The main disadvantage of this model is that the code-behind file in the background must be synchronized with the aspx page. Even from the programming perspective, the ASPX page is inherited from the background code file, and there is actually a more complex relationship between the two.
      1. Complexity of Inheritance Complexity Inheritance
         If controls were added to the ASPX page, new code had to be added to the code-behind file. in other words, despite the inheritance relationship pointing the other way, the ASPX page actually drove the design of the code-behind file.
         That is to say, although the ASPX page inherits from the Code behind file, the ASPX page also restricts the design of the code-behine file.
      2. Complexity of Compilation Complexity Compilation
         All of the code-behind files were compiled into an assembly and stored in the/bin directory of the Web application. The compilation stepOccurred prior to deployingThe application. On the other hand, the ASPX page was compiled at runtimeFirst time the page was requested. The ASP. NET runtime actually compiled the ASPX page into its own temporary assembly.
         Both the ASPX page and the code-behind file need to be compiled, but the time is different. The code-behind file is compiled before deployment, and the ASPX page is temporarily compiled at the time of the first request.
         The problem with this process is that the ASPX page can be changed without updating the code-behind assembly. That is, a developer may choose to modify a property orChange the type of a controlOn an ASPX page after deployment, and the code-behind file wocould not be updated, nor wocould the application assembly be recompiled.
         Obviously, if the control type of the ASPX page is modified after deployment, the code-behind file must be re-compiled.