ASP.NET applications
The difference between web applications and rich client applications makes a lot of sense when you consider the ASP.NET execution model. Unlike a rich client application, the user never runs an ASP.NET application directly or any web application for that matter. Instead, a user launches a browser and requests a specific URL over HTTP. This request is received by a web server. The web server has no concept of separate application; it simply passes the request to the ASP.NET process. However, the ASP.NET process carefully separates code execution into different application domains based on the virtual directory. Web pages that are hosted in the same virtual directory (or one of its subdirectories) execute in the same application domain.
The Application Domain
An application domain is a boundary enforced by the CLR(dot net runtime engine) that ensures that one application can’t influence another. The following characteristics are a direct result of the application domain model:
1. All the web pages in a single web application share the same in-memory resources, such as global application data, per-user session data, and cached data.
2. All the web pages in a single web application share the same core configuration settings. However, you can customize some configuration settings in individual subdirectories of the same virtual directory. For example, you can set only one authentication mechanism for a web application, no matter how many subdirectories it has. However, you can set different authorization rules in each directory to fine-tune who is allowed to access different groups of pages.
3. All web applications raise global application events at various stages (when the application domain is first created, when it’s destroyed). You can attach event handlers that react to these global application events using code in the global.asax file in your application’s virtual directory.
Essentially, the virtual directory is the basic grouping structure that defines an ASP.NET application. ASP.NET applications can include files such as:
1. Web pages (.aspx files)
2. Web services (.asmx files):
3. Code-behind files: If you are using the code behind model, you may have separate source code files.
4. A configuration file (web.config): This file contains application-level settings that configure everything including security, debugging and state management.
5. global.asax: This file contains event handlers that react to global application events (such as when the application is first being started).
6. Other components: These are compiled assemblies that contain separate components with useful functionality. Components allow you to separate business and data access logic and create custom controls.
7. Other files and resources that ASP.NET web applications will use, including stylesheets, images, XML files
Application Lifetime
ASP.NET uses a lazy initialization technique for creating application domains. This means that the application domain for a web application is created the first time a request is received for a page in that application. An application domain can shut down for a variety of reasons, including if the web server itself shuts down. But, more commonly, applications restart themselves in new application domains in response to error conditions or configuration changes. This model is designed to keep an application healthy and to detect characteristics that could indicate a problem has developed or performance of the application has degraded (such as a long queue of outstanding requests, a huge amount of memory in use, and so on). Depending on your machine.config settings, application domains may be recycled based on the length of time the application domain has been running, the number of queued requests, or the amount of memory used . ASP.NET automatically recycles application domains when you change the application. For example if you modify the web.config file. Another example is if you replace an existing web-page file or DLL assembly file. In both of these cases, ASP.NET starts a new application domain to handle all future requests and keeps the existing application domain alive long enough to finish handling any outstanding requests (including queued requests).
Application Updates
One of the most remarkable features about the ASP.NET execution model is that you can update your web application without needing to restart the web server and without worrying about affecting existing clients. This means you can add, replace, or delete files in the virtual directory at any time. Being able to update any part of an application at any time without interrupting existing requests is a powerful feature. However, it’s important to understand the architecture that makes it possible. It’s not a feature of the CLR that allows ASP.NET to seamlessly transition to a new application domain. In reality, the CLR always locks assembly files when it executes them. To get around this limitation, ASP.NET doesn’t actually use the ASP.NET files in the virtual directory. Instead, it uses another technique, called shadow copy, during the compilation process it creates copies of your files .The ASP.NET worker process loads the assemblies from this directory, which means these assemblies are locked. The second part of the story is ASP.NET’s ability to detect when you change the original files , it simply relies on the ability of the Windows operating systemto track directories and files and send immediate change notifications. ASP.NET maintains an active list of all assemblies loaded within a particular application’s application domain and uses monitoring code to watch for changes and acts accordingly.
Application Directory Structure
Every web application should have a well-planned directory structure. Independently from the directory structure you design, ASP.NET defines a few directories with special meanings:
Bin
This directory contains all the precompiled .NET assemblies (DLLs) that the ASP.NET web application uses. These assemblies can include precompiled web-page classes, as well as other assemblies referenced by these classes.
App_Code
This directory contains source code files that are dynamically compiled for use in your application. These code files are usually separate components, such as a logging component or a data access library.
App_GlobalResources
This directory stores global resources that are accessible to every page in the web application.
No comments:
Post a Comment