asp.net jayesh Patel, Bryan Acker and Robert McGovern
Infusion Development
Scope of application:
Microsoft asp.net 2.0
Absrtact: Although ASP.net 2.0 is completely backward-compatible with ASP.net 1.1, it also brings a lot of internal changes to ASP.net, including code model, compilation, page lifecycle, and so on. This article provides an overview of these changes.
Content of this page
Introduction
Code Model
Compile
Compile at full runtime (code directory)
Page life cycle
Scalability
Advanced caching Technology
Performance
Conclusion
Introduction
For professional asp.net developers, the important question associated with ASP.net 2.0 is what has changed internally. While the new features are interesting and interesting to learn, for developers who really want to master the technology, the change in the core structure of the asp.net is what attracts them most. In this paper, we will describe how the internal structure of ASP.net 2.0 has changed since version 1.x.
The topics presented in this paper are useful for developers who are concerned with performance and for technical designers looking for ways to optimize applications. Specifically, we'll describe the main issues with code model, compilation, page lifecycle, scalability, performance, and caching.
Many of the examples in this article require you to have a considerable degree of understanding of ASP.net, Visual Basic. NET and/or C # syntax. This article also provides a reference document where appropriate, with in-depth discussions on specific topics.
Back to the top of the page
Code Model
Perhaps the most obvious change in ASP.net 2.0 's internal work style is the change in how the Web page is created asp.net. This section describes the changes that have occurred in the underlying code model and the impact of these changes on asp.net development.
Code model in the ASP.net 1.x
In ASP.net 1.x, there are two main options for developers to develop WEB forms. First, developers can refer to the traditional ASP model and write code directly in the ASPX page. This process is known as "inline code," and it works well for simple commands. However, for more complex code, writing inline code will make it difficult to read Web pages that mix presentation (HTML) and functionality (code). In asp.net, the default encoding method has been changed to help resolve this problem. You can write business logic and event-handling code in a separate, code-only file, called a "code-behind" file. The built-in code model links files that contain only code to the ASPX file that contains the token. By separating the code from the presentation, the development team can allow the designer to work with the demo file and let the developer process the code files to improve the team's productivity.
Figure 1:asp.net 1.x code Model
The main difficulty with the embedded code model is how to keep the embedded code file synchronized with the ASPX page. Although the ASPX page is programmatically inherited from the embedded code file, the two files are actually linked through more complex relationships.
For more information about the embedded code model in ASP.net 1.x, see the MSDN Library article Web Forms Code Models (English).
Complexity of inheritance
The ASP.net design pattern is to let developers use Microsoft Visual Studio. NET to drag and drop controls onto an ASPX page. Visual Studio will then automatically generate the appropriate support code in the embedded code file. If the control has been added to the ASPX page, you must add the new code in the embedded code file. In other words, although the ASPX page inherits from the embedded code file, the ASPX page actually pushes the design of the embedded code file.
Complexity of compilation
The second synchronization problem is how to compile the file. All the embedded code files and all support classes are compiled into an assembly and stored in the/bin directory of the WEB application. The compilation of the application is done before the deployment work. ASPX pages, on the other hand, are compiled at run time the first time they are requested. The ASP.net runtime actually compiles an ASPX page into its own temporary assembly on the page.
The problem with this process is that you can change the ASPX page without updating the containing code assembly. That is, developers can change a property after deployment or change the type of a control on an ASPX page without having to update the containing code file or recompiling the application's assembly. When this occurs, the application may experience unexpected errors because the containing code file does not match the associated ASPX page.
Code model in asp.net 2.0
ASP.net 2.0 continues to provide inline code and embedded code models. From the perspective of the inline code model, there has been little change in the way that Microsoft Visual Studio 2005 supports single file development. For more information about the changes in Visual Studio 2005 and how to handle inline code, see this article.
ASP.net 2.0 solves the problem of inheritance and compilation of the embedded code model by changing the nature of the embedded code file. In asp.net 2.0, the embedded code file is no longer a complete implementation of the System.Web.UI.Page class. Instead, the embedded code file is a new constructor called a "local class." The local class contains all user-defined code, but does not contain any pipeline and connection code that is automatically generated by Visual Studio. NET in asp.net 1.x. When you request an ASPX page that contains a new embedded code file, the ASP.net 2.0 runtime actually merges the ASPX page and the local class into one class instead of two separate classes.
The embedded code model in Figure 2:asp.net 2.0
The local class uses the New keyword (expands in Visual Basic, and Partial in C #) to indicate that the code in the class is merged with the code in another class at run time. Similarly, the ASPX page uses a new directive, called Compilewith, to indicate the relationship between the page and the containing code file.
Compare the embedded code files
If you are familiar with the traditional ASP.net 1.x code file, you should know that Visual Studio inserts the automatically generated control declaration and initialization code. This auto-generated code is a direct result of a two-way synchronization between a code file and an ASPX file. A typical ASPX page with a label has a corresponding code file that consists of a number of automatically generated lines of text.
List 1:asp.net code files in 1.x
Namespace WebApplication1
{
public class WebForm1:System.Web.UI.Page
{
protected System.Web.UI.WebControls.Label Label1;
private void Page_Load (object sender,
System.EventArgs e) {}
#region Web Form Designer generated code
Override protected void OnInit (EventArgs e)
{
InitializeComponent ();
Base. OnInit (e);
}
private void InitializeComponent ()
{
This. Load + = new System.EventHandler (this. Page_Load);
}
#endregion
}
}
The auto-generated code not only defines the label (the rows shown in bold), but also declares a new event (page load) and automatically binds the event to the Auto-generated method wrapper (Page_Load ()).
In comparison, the embedded code file generated by the same asp.net page in asp.net 2.0 is simpler.
List 2:asp.net code files in 2.0.x
Namespace ASP {
public partial class Webform1_aspx
{
}
}
Developers can automatically access Label1 and add events as needed. For example, you can add a Page_Load event to initialize the label.
Listing 3: Adding events to a new embedded code file
Namespace ASP {
public partial class Webform1_aspx
{
void Page_Load (object sender, EventArgs e)
{
Label1.Text = "Hello asp.net 2.0";
}
}
}
Event syntax can be generated through Visual Studio. NET. The generated embedded code file is shorter and does not contain any auto-generated code. The asp.net runtime automatically binds the events in the embedded code file to the controls on the ASPX page. In other words, the ASP.net runtime can now automate code generation, which was originally performed by Visual Studio.
Complexity of inheritance
The new embedded code model greatly reduces the complexity of inheritance. Because ASPX pages are not directly inherited from the embedded code file, the embedded code file no longer needs to define and support all the controls defined on the ASPX page. Similarly, an embedded code file can automatically access any control on an ASPX page without having to declare code (the declaration code is required in ASP.net 1.x). This is possible because the ASP.net runtime can automatically insert the required declaration code and event-binding code into the final compiled file. Because these work is done by the runtime, neither the code developer nor the Web developer needs to worry about the problem.
During design time, the links are maintained by Visual Studio 2005来. The Visual Studio environment will use the ASP.net run-time compile segment to ensure that code developers and WEB developers can work synchronously.
Complexity of compilation
Because the new embedded code file is linked to the ASPX page and is compiled into a complete class at run time, the complexity of the compilation no longer exists. That is, the embedded code file is automatically synchronized with the ASPX page. Even if the new compilation model may contain unsynchronized code, it is due to the production
