The Three Architectures of ASP.NET
There are three (3) architectures available with Web applications – depending on if you’re working with a Web Site
or Web Application Project and the page model you choose. Web Application Projects always use code-behind
Web pages. Web Sites, however, support both the single-file and code-behind models. The architecture of these
three types of Web pages is quite different.
Web Application Projects insist that all Web pages are broken into three separate files.
The Default.aspx file will be compiled as the ASP.default_aspx class that inherits from _Default. The _Default
class is partially defined in both Default.aspx.cs and Default.aspx.designer.cs. It inherits from the Page class.
Default.aspx.cs holds the event handlers and all custom code while Default.aspx.designer.cs contains the control
declarations, including the form declaration itself. All code-behind files are compiled together into one dynamic-link
library (DLL) in the bin folder. Web Application Projects have a References folder.
This diagram shows the architecture of a Web Application Project:
When you study the source code of these files, the hierarchy becomes even more apparent. You’ll notice that the
Web Application Project uses a root level namespace (WebApplication1) as the container for all Web pages. This
namespace is referenced in Default.aspx, where it states that in inherits from the WebApplication1._Default class.
Default.aspx.cs
namespace WebApplication1
{
public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
}
}
Default.aspx.designer.cs
namespace WebApplication1
{
public partial class _Default
{
/// <summary>
/// form1 control.
/// </summary>
/// <remarks>
/// Auto-generated field.
/// To modify move field declaration from designer file to code-behind.
/// </remarks>
protected global::System.Web.UI.HtmlControls.HtmlForm form1;
/// <summary>
/// Button1 control.
/// </summary>
/// <remarks>
/// Auto-generated field.
/// To modify move field declaration from designer file to code-behind.
/// </remarks>
protected global::System.Web.UI.WebControls.Button Button1;
}
}
Default.aspx
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"
Inherits="WebApplication1._Default" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.
org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
… REMAINING HTML SNIPPED …
On the other hand, Web Sites (different from Web Application Projects) support both the single-file and code-
behind model. Remember - Web Sites do not have all of their code-behind files compiled into one DLL in the bin
subfolder. Each Web page is compiled into an individual assembly located in system-controlled folder under
“Temporary ASP.NET Files”. This assembly is automatically JIT-compiled when any of the code changes in the
ASPX file or its related code-behind file.
This Web Site shows two different Web pages, Default.aspx and Default2.aspx.
As you can see in the picture above, Default.aspx is using the single-file model while Default2.aspx is using the
code-behind model. The ASP.NET framework automatically detects changes to any of the files, “invalidates” the
existing JIT-compiled assemblies and rebuilds them. Thankfully, it’s all handled for you automatically!
Both pages are ultimately compiled into an assembly, as you can see here:
Note how each Web page is compiled into one assembly with each Web page being represented by a “.compiled”
file. Additional files and folders are automatically created throughout the lifetime of the Web Site on each particular
Web server. The weird file and folder names are unique per Web server and managed by the .NET framework. As
you make changes to the Web Site, you may see “.delete” files appear here, which is how .NET invalidates and
rebuilds Web pages.
Thankfully, you don’t need to bother with these files when you redistribute your Web Site. You can learn more
about the files managed here by reading the .NET SDK and by opening the files with either Notepad or a hex editor.
Here is the architecture of a Web Site with the code-behind model:
In the middle of the diagram on the right side, note that the control and form declarations are created in a file
automatically – we can’t even find it to open it! It’s still a partial class definition of the _Default class; however, it’
s created and controlled by the .NET framework. Careful snooping in the “Temporary ASP.NET Files” folder
may help you find this secret file.
Finally, here is the architecture of a Web Site with the single-file model:
Since there is no code-behind file, all declarations and .NET code is compiled into one class that inherits directly
from the Page class. This model actually removes one level of inheritance, possibly offering a decrease in memory
use and a slight performance gain. The single-file and code-behind models warrant a closer look at the single-file and
code-behind models.
There are three (3) architectures available with Web applications – depending on if you’re working with a Web Site
or Web Application Project and the page model you choose. Web Application Projects always use code-behind
Web pages. Web Sites, however, support both the single-file and code-behind models. The architecture of these
three types of Web pages is quite different.
Web Application Projects insist that all Web pages are broken into three separate files.
The Default.aspx file will be compiled as the ASP.default_aspx class that inherits from _Default. The _Default
class is partially defined in both Default.aspx.cs and Default.aspx.designer.cs. It inherits from the Page class.
Default.aspx.cs holds the event handlers and all custom code while Default.aspx.designer.cs contains the control
declarations, including the form declaration itself. All code-behind files are compiled together into one dynamic-link
library (DLL) in the bin folder. Web Application Projects have a References folder.
This diagram shows the architecture of a Web Application Project:
When you study the source code of these files, the hierarchy becomes even more apparent. You’ll notice that the
Web Application Project uses a root level namespace (WebApplication1) as the container for all Web pages. This
namespace is referenced in Default.aspx, where it states that in inherits from the WebApplication1._Default class.
Default.aspx.cs
namespace WebApplication1
{
public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
}
}
Default.aspx.designer.cs
namespace WebApplication1
{
public partial class _Default
{
/// <summary>
/// form1 control.
/// </summary>
/// <remarks>
/// Auto-generated field.
/// To modify move field declaration from designer file to code-behind.
/// </remarks>
protected global::System.Web.UI.HtmlControls.HtmlForm form1;
/// <summary>
/// Button1 control.
/// </summary>
/// <remarks>
/// Auto-generated field.
/// To modify move field declaration from designer file to code-behind.
/// </remarks>
protected global::System.Web.UI.WebControls.Button Button1;
}
}
Default.aspx
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"
Inherits="WebApplication1._Default" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.
org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
… REMAINING HTML SNIPPED …
On the other hand, Web Sites (different from Web Application Projects) support both the single-file and code-
behind model. Remember - Web Sites do not have all of their code-behind files compiled into one DLL in the bin
subfolder. Each Web page is compiled into an individual assembly located in system-controlled folder under
“Temporary ASP.NET Files”. This assembly is automatically JIT-compiled when any of the code changes in the
ASPX file or its related code-behind file.
This Web Site shows two different Web pages, Default.aspx and Default2.aspx.
As you can see in the picture above, Default.aspx is using the single-file model while Default2.aspx is using the
code-behind model. The ASP.NET framework automatically detects changes to any of the files, “invalidates” the
existing JIT-compiled assemblies and rebuilds them. Thankfully, it’s all handled for you automatically!
Both pages are ultimately compiled into an assembly, as you can see here:
Note how each Web page is compiled into one assembly with each Web page being represented by a “.compiled”
file. Additional files and folders are automatically created throughout the lifetime of the Web Site on each particular
Web server. The weird file and folder names are unique per Web server and managed by the .NET framework. As
you make changes to the Web Site, you may see “.delete” files appear here, which is how .NET invalidates and
rebuilds Web pages.
Thankfully, you don’t need to bother with these files when you redistribute your Web Site. You can learn more
about the files managed here by reading the .NET SDK and by opening the files with either Notepad or a hex editor.
Here is the architecture of a Web Site with the code-behind model:
In the middle of the diagram on the right side, note that the control and form declarations are created in a file
automatically – we can’t even find it to open it! It’s still a partial class definition of the _Default class; however, it’
s created and controlled by the .NET framework. Careful snooping in the “Temporary ASP.NET Files” folder
may help you find this secret file.
Finally, here is the architecture of a Web Site with the single-file model:
Since there is no code-behind file, all declarations and .NET code is compiled into one class that inherits directly
from the Page class. This model actually removes one level of inheritance, possibly offering a decrease in memory
use and a slight performance gain. The single-file and code-behind models warrant a closer look at the single-file and
code-behind models.
The Three Architectures of ASP.NET
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
Services