Interpreting ASP.net 2.0 Internals

asp.net Introduction
New features are fun and interesting to learn about, but changes to the core structure of asp.net speak-louder to develope Rs who really want to master the technology. In this white paper, we'll cover how the internal structure of ASP.net 2.0-has changed since version 1.x.
Overview of changes to the core structure of asp.net1.0 to asp.net2.0

The topics covered in this paper would be is of use to performance-minded developers and technical architects to seeking Tune (adjust, make a rule) applications. Specifically, we'll examine key areas of the code model, compilation, page lifecycle, extensibility, performance, and CA Ching.
This topic is used by developers and technical architects who focus on performance to adjust the application now. and focus on the code model, compilation, page lifetime, scalability, performance and caching, and many other aspects.

Code Model
How a asp.net Web page is created now
Coding Models in asp.net 1.
Two primary options for developing a Web Form.
Code-inline, works very-for-simple commands. However, for more complex code, writing Code-inline results in difficult to read Web pages that mix presentation (HTML) WI Th functionality (code).
Code inline mode only applies to simple commands
Code-behind
Business Logic and Event-handling code could is 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" presentation, development teams could work by faster the "allowing to" on the Presentation file While the developers worked on the code file.
Business logic and event handler code separate from presentation pages

The difficulties in 1.x 1.x insufficiency
The primary difficulties with the Code-behind model related to the way in which the Code-behind file had to be synchronize D with the ASPX page. Although the ASPX page inherited from the Code-behind file in a programming sense, the two files were actually to coupled by A more complex relationship.
The main problem with this model is that the background code files Code-behind file must be synchronized with the ASPX page. Even from a programmatic point of view, ASPX pages are inherited from the background code file, and there is actually a more complex relationship between the two.
Complexity of inheritance complexity inheritance
If controls were added to the ASPX page, the new code had to the added file. In other words, despite the inheritance relationship pointing the other way, the ASPX page actually drove the "design of TH" e code-behind file.
That is, while an ASPX page inherits from code behind file, the actual ASPX page in turn restricts the design of code-behine file.
Complexity of compilation Complexity compilation
All of the Code-behind files were compiled into a assembly and stored in The/bin directory of the WEB application. The compilation step occurred prior to deploying the application. On the other hand, the ASPX page is compiled at runtime the "the" the page was requested. The ASP.net runtime actually compiled the ASPX page into its own temporary.
Both the ASPX page and the Code-behind file need to be compiled, but the time is mixed, Code-behind file is compiled before deployment, and the ASPX page is temporarily compiled at the first time it is requested.
The problem and this process is the ASPX page can be changed without updating the Code-behind assembly. It, a developer may choose to modify a property or change the type of a control on a ASPX page after deployment, and The Code-behind file would is updated, nor would the application assembly be recompiled.
Obviously, the control type of the ASPX page is modified after deployment, and Code-behind file must be recompiled.

To be Continued ...