Beginning Web Development, Silverlight, and ASP.NET AJAX

38
CHAPTER 3 ■ WEB FORMS WITH ASP.NET
Web applications are multiuser: When building an application for the Web, you have
to remember that your application should be designed to be scaled out to many
users, which in some cases can number in the millions. This leads to two major challenges.
The first is that when the application has to scale out to huge numbers of
users, it will operate in a clustered environment, meaning that it is deployed to a
number of servers, and the clustering hardware manages who speaks to which
server. In an environment such as this, you have to make sure that the experience
each user has when using your application is consistent. Thus, a level of commonality
is necessary, and this is achieved using shared pools of resources such as data,
styling, and connectivity to outside applications. You have to make sure that your
application cooperates with other instances of itself in accessing shared application
resources. Similarly, you have to make sure that the users accessing your application
are doing so concurrently, leading to potential concurrency issues. This means that
you have to be careful in how you write classes that are going to be shared by user
sessions. The framework helps you in this regard, but it doesn’t do everything for you.
Your user classes will need to be carefully crafted and deployed.
Web applications are designed to execute on a server and be viewed in a browser: Your
application is used within users’ browsers on their machines, but the application
actually executes (for the most part) on your server. So, if you think about the simple
case where the user is filling out a form on the browser (like our stock quote application
in Chapter 2), what is happening is that the user sets the state of some of the
controls in the form and invokes an HTML form data submission process, which
sends the data to the server. The server executes the application and then returns the
results to the client. This process is called a postback. Newer application programming
interfaces (APIs) and methodologies such as Ajax move some of the processing
to the client, providing a richer client experience (they make more frequent asynchronous
postbacks to the server to make the application appear more responsive),
but your web applications still have a server element to them, and understanding
how to handle this is vital as you write your web applications.
Typical web applications are stateless: To maintain a clean relationship between the
client and the server, particularly to avoid confusion when in a clustered environment,
no state of the condition of a client is stored on the server in a typical web
application. This can be overridden to some degree, but the typical scenario has the
server destroy all instances of web page objects residing in its memory for a particular
page once the page has been sent to the client. This is great for scalability, but it
can hurt the user and developer experience—for example, when information should
be persisted throughout a number of sessions and a mechanism has to be grown to
achieve this. ASP.NET assists you in building applications that maintain state
through a process called view state, in which information about the form can be
stored in hidden HTML form fields. You’ll be looking at view state a little later in this