لطفا منتظر باشید ...
Publisher2.2 Application Structure and Boundaries
Although
it is convenient, for the sake of discussing application types, to
divide ASP.NET applications into web applications and web services,
the truth is that from a practical standpoint, ASP.NET applications
can be comprised of both types; an ASP.NET Web Application may
contain
.asmx files that implement web services,
and a web service application may contain
.aspx
files that implement user interfaces for web services or
functionality contained in .NET assemblies. Thus, from the standpoint
of application structure, ASP.NET Web Applications and ASP.NET Web
Services are quite similar.
2.2.1 Application Structure
The structure of an ASP.NET application consists of a site or virtual
directory in IIS and at least one ASP.NET page or web service.
Optionally, each ASP.NET application may have:
A single
global.asax file, located in the root
of the application.
One or more
web.config files. There can be only
one
web.config file per directory or
subdirectory in the application.
One or more User Control files bearing the
.ascx
extension.
One or more class files, either for ASP.NET code-behinds or for
assemblies used in your application.
A /bin directory containing .NET assemblies you
wish to use in your application. Assemblies in the
/bin directory are automatically made available
to your application.
ASP.NET Web Applications created in Visual Studio .NET contain
Solution and Project-related files (
.sln ,
.suo ,
.vbproj , and
.csproj , for example), and an optional default
cascading style sheets file (
.css ). These
applications may also optionally contain resource files
(
.resx) , dataset and/or XML schema definitions
(
.xsd ), and other file types.
Any other type of file (
,
.asp , images, etc.) that you'd
expect a classic web application to contain. Note, however, that
.asp pages within an ASP.NET application will
not share an Application and Session state with the ASP.NET
application.
Figure 2-3 provides a visual explanation of how an
ASP.NET application is structured.
Figure 2-3. Structure of an ASP.NET application
2.2.2 Application Boundaries
In
ASP.NET, as in classic ASP, the boundary of an application is
determined primarily by the site or virtual directory defined for
that application in IIS. Requests for ASP.NET pages or web services
that reside within that site or virtual directory and its
subdirectories are treated as part of the application and have access
to application-specific items such as the Application and Session
intrinsic objects (provided, respectively, by the
HttpApplicationState and
HttpSessionState classes). They also share
resources with other requests to the application.
2.2.3 Request Lifecycle and Handling
When a request comes in from a
client for a file within the purview of IIS (i.e., an HTTP request
for a file within one of the sites or virtual directories set up in
IIS), IIS checks the file extension of the file being requested and
then checks its mapping of file types to handler programs to
determine which program should be used to process the request. In the
case of a classic ASP application, a request for a file with the
.asp extension is handled by the
asp.dll ISAPI application. The App Mappings tab
of the Application Configuration dialog for IIS, shown in Figure 2-4, allows you to view and modify the mappings of
file extensions to the executables used to handle those extensions,
as well as to determine the HTTP verbs (GET, POST, etc.) that qualify
the mapping.
Figure 2-4. The IIS Application Configuration dialog
Requests for files with the
.aspx and
.asmx extensions and for other ASP.NET-related
files are handled by the
aspnet_wp.dll ISAPI
application. This application, in turn, hands the requests off to the
aspnet_wp.exe worker process. Once the request
is handed off to the ASP.NET worker process, it handles the rest of
the processing by:
JIT (just in time)-compiling the code in the page (and in any
code-behind page identified with the src
attribute) if no cached compiled version of the requested resource
exists.
Executing the compiled assembly associated with the page or web
service, including refreshing any control or page state from a
previous request, handling events raised by the request, and
rendering the appropriate output to the client.
Releasing used resources and discarding any transient state
information (information not stored in either the Application or
Session state collections).
With the exception of the Application state collection, which is
available to all clients within a given ASP.NET application, and the
Session state collection, which is associated with a specific client
by a value either stored in an HTTP cookie on the client or munged
into the URL for the application, each individual request to the
application is independent from any other, even for that client.
The practical effect is that each request must contain sufficient
information to successfully process the requestwhether that
information comes from form fields passed from the client,
information stored in the Application or Session collections, or even
information from cookies or a database.
