ASP.NET
ASP.NET is a
server-side Web application framework designed for
Web development to produce
dynamic Web pages. It was developed by
Microsoft to allow
programmers to build dynamic
web sites,
web applications and
web services. It was first released in January 2002 with version 1.0 of the
.NET Framework, and is the successor to Microsoft's
Active Server Pages (ASP) technology. ASP.NET is built on the
Common Language Runtime (CLR), allowing programmers to write ASP.NET code using any supported
.NET language. The ASP.NET
SOAP extension framework allows ASP.NET components to process SOAP messages.
Characteristics
ASP.NET Web pages, known officially as Web Forms,
are the main building blocks for application development.
[3] Web forms are contained in files with a ".aspx" extension; these files typically contain static (
X)
HTML markup, as well as markup defining server-side Web Controls and User Controls where the developers place all the rc content
[further explanation needed] for the Web page. Additionally, dynamic code which runs on the server can be placed in a page within a block
<% -- dynamic code -- %>, which is similar to other Web development technologies such as
PHP,
JSP, and
ASP. With
ASP.NET Framework 2.0, Microsoft introduced a new
code-behind
model which allows static text to remain on the .aspx page, while
dynamic code remains in an .aspx.vb or .aspx.cs or .aspx.fs file
(depending on the programming language used)
User controls
User controls are encapsulations of sections of pages which are registered and used as controls in ASP.NET, etc.
Custom controls
Programmers can also build
custom controls for ASP.NET
applications. Unlike user controls, these controls do not have an ASCX
markup file, having all their code compiled into a
dynamic link library (DLL) file. Such custom controls can be used across multiple Web applications and
Visual Studio projects.
Rendering technique
ASP.NET uses a "visited composites" rendering technique. During
compilation, the template (.aspx) file is compiled into initialization
code which builds a control tree (the composite) representing the
original template. Literal text goes into instances of the Literal
control class, and server controls are represented by instances of a
specific control class. The initialization code is combined with
user-written code (usually by the assembly of multiple partial classes)
and results in a class specific for the page. The page doubles as the
root of the control tree.
Actual requests for the page are processed through a number of steps.
First, during the initialization steps, an instance of the page class
is created and the initialization code is executed. This produces the
initial control tree which is now typically manipulated by the methods
of the page in the following steps. As each node in the tree is a
control represented as an instance of a class, the code may change the
tree structure as well as manipulate the properties/methods of the
individual nodes. Finally, during the rendering step a visitor is used
to visit every node in the tree, asking each node to render itself using
the methods of the visitor. The resulting HTML output is sent to the
client.
After the request has been processed, the instance of the page class
is discarded and with it the entire control tree. This is a source of
confusion among novice ASP.NET programmers who rely on the class
instance members that are lost with every page request/response cycle.
State management
ASP.NET applications are hosted by a
Web server and are accessed using the
stateless HTTP protocol. As such, if an application uses stateful interaction, it has to implement
state management on its own. ASP.NET provides various functions for state management. Conceptually, Microsoft treats "state" as
GUI state. Problems may arise if an application needs to keep track of "data state"; for example, a
finite-state machine which may be in a transient state between requests (
lazy evaluation) or which takes a long time to initialize. State management in ASP.NET pages with authentication can make
Web scraping difficult or impossible.
Application
Application state is held by a collection of shared user-defined variables. These are set and initialized when the
Application_OnStart
event fires on the loading of the first instance of the application and
are available until the last instance exits. Application state
variables are accessed using the
Applications collection, which provides a wrapper for the application state. Application state variables are identified by name.
[6]
Session state
Server-side session state is held by a collection of user-defined
session variables that are persistent during a user session. These
variables, accessed using the
Session collection, are
unique to each session instance. The variables can be set to be
automatically destroyed after a defined time of inactivity even if the
session does not end. Client-side user session is maintained by either a
cookie or by encoding the session ID in the URL itself.
[6]
ASP.NET supports three modes of persistence for server-side session variables:
- In-process mode
- The session variables are maintained within the ASP.NET process. This is the fastest way; however, in this mode the variables are destroyed when the ASP.NET process is recycled or shut down.
- State server mode
- ASP.NET runs a separate Windows service
that maintains the state variables. Because state management happens
outside the ASP.NET process, and because the ASP.NET engine accesses
data using .NET Remoting, ASPState is slower than In-Process. This mode
allows an ASP.NET application to be load-balanced and scaled across
multiple servers. Because the state management service runs
independently of ASP.NET, the session variables can persist across
ASP.NET process shutdowns. However, since session state server runs as
one instance, it is still one point of failure for session state. The
session-state service cannot be load-balanced, and there are
restrictions on types that can be stored in a session variable.
- SQL Server mode
- State variables are stored in a database,
allowing session variables to be persisted across ASP.NET process
shutdowns. The main advantage of this mode is that it allows the
application to balance load on a server cluster, sharing sessions
between servers. This is the slowest method of session state management
in ASP.NET.
ASP.NET session state enables you to store and retrieve values for a
user as the user navigates ASP.NET pages in a Web application. HTTP is a
stateless protocol. This means that a Web server treats each HTTP
request for a page as an independent request. The server retains no
knowledge of variable values that were used during previous requests.
ASP.NET session state identifies requests from the same browser during a
limited time window as a session, and provides a way to persist
variable values for the duration of that session. By default, ASP.NET
session state is enabled for all ASP.NET applications.
Alternatives to session state include the following:
- Application state, which stores variables that can be accessed by all users of an ASP.NET application.
- Profile properties, which persists user values in a data store without expiring them.
- ASP.NET caching, which stores values in memory that is available to all ASP.NET applications.
- View state, which persists values in a page.
- Cookies.
- The query string and fields on an HTML form that are available from an HTTP request.
For a comparison of different state-management options, see ASP.NET State Management Recommendations Session
View state
View state refers to the page-level state management mechanism,
utilized by the HTML pages emitted by ASP.NET applications to maintain
the state of the Web form controls and
widgets. The state of the controls is encoded and sent to the server at every form submission in a hidden field known as
__VIEWSTATE.
The server sends back the variable so that, when the page is
re-rendered, the controls render at their last state. At the server
side, the application may change the viewstate, if the processing
requires a change of state of any control. The states of individual
controls are decoded at the server, and are available for use in ASP.NET
pages using the
ViewState collection.
The main use for this is to preserve form information across postbacks. View state is turned on by default and normally
serializes
the data in every control on the page regardless of whether it is
actually used during a postback. This behavior can (and should) be
modified, however, as View state can be disabled on a per-control,
per-page, or server-wide basis.
Developers need to be wary of storing sensitive or private information in the View state of a page or control, as the
base64 string containing the view state data can easily be de-serialized. By default, View state does not encrypt the
__VIEWSTATE
value. Encryption can be enabled on a server-wide (and server-specific)
basis, allowing for a certain level of security to be maintained.
Server-side caching
ASP.NET offers a "Cache" object that is shared across the application
and can also be used to store various objects. The "Cache" object holds
the data only for a specified amount of time and is automatically
cleaned after the session time-limit elapses.
Other
Other means of state management that are supported by
ASP.NET are
cookies,
caching, and using the
query string.
Template engine
When first released, ASP.NET lacked a
template engine. Because the
.NET Framework is
object-oriented and allows for
inheritance, many developers would define a new base class that inherits from "System.Web.UI.Page", write
methods
there that render HTML, and then make the pages in their application
inherit from this new class. While this allows for common elements to be
reused across a site, it adds complexity and mixes
source code with
markup.
Furthermore, this method can only be visually tested by running the
application – not while designing it. Other developers have used
include files and other tricks to avoid having to implement the same navigation and other elements in every page.
ASP.NET 2.0 introduced the concept of "master pages", which allow for
template-based page development. A Web application can have one or more master pages, which, beginning with ASP.NET 2.0, can be nested.
[10] Master templates have place-holder controls, called
ContentPlaceHolders to denote where the dynamic content goes, as well as
HTML and
JavaScript shared across child pages.
Child pages use those ContentPlaceHolder controls, which must be
mapped to the place-holder of the master page that the content page is
populating. The rest of the page is defined by the shared parts of the
master page, much like a
mail merge in a
word processor. All markup and
server controls in the content page must be placed within the ContentPlaceHolder control.
When a request is made for a content page, ASP.NET merges the output
of the content page with the output of the master page, and sends the
output to the user.
The master page remains fully accessible to the content page. This
means that the content page may still manipulate headers, change title,
configure caching etc. If the master page exposes public properties or
methods (e.g. for setting copyright notices) the content page can use
these as well.
Best of luck, will be back with more of Web Development
