Understanding the Internet as an Infrastructure

The Internet is a big network (all right—a really big network), and, as a result, the information and data that you can access over it can be quite remote. This should have an impact on the way you design your applications. For example, you might get away with repeatedly querying and fetching individual rows of data held in a database while a user browses it in a small, local desktop application, but this strategy will not be feasible for an application that runs over the Internet. Resource use affects scalability much more for the Internet than it does for local applications.

Network bandwidth is a scarce resource that should be used sparingly. You might notice variations in the performance of your own local network according to the time of day (networks always seem to slow down on a Friday afternoon just when you are trying to get everything done before the weekend), the applications that users in your company are running, and many other factors. But no matter how variable the performance of your own local network is, the Internet is far less predictable. You are dependent on any number of servers routing your requests from your Web browser to the site you are trying to access, and the replies can get passed back along an equally tortuous route. The network protocols and data presentation mechanisms that underpin the Internet reflect the fact that networks can be (and at times most certainly will be) unreliable and that a Web application can be accessed concurrently from many different Web browsers running on many different operating systems.

Understanding Web Server Requests and Responses

A Web browser communicates with a Web application over the Internet by using the Hypertext Transfer Protocol (HTTP). Web applications are usually hosted by some sort of Web

server that reads HTTP requests and determines which application should be used to respond to the request. The term application in this sense is a very loose term—the Web server might

invoke an executable program to perform an action, or it might process the request itself by using its own internal logic or other means. However the request is processed, the Web server will send a response to the client, again by using HTTP. The content of an HTTP response is usually presented as a Hypertext Markup Language (HTML) page; this is the language that most browsers understand and know how to render.

Note Applications run by users that access Web applications over the Internet are often referred to as clients or client applications.

Managing State

HTTP is a connectionless protocol. This means that a request (or a response) is a stand-alone packet of data. A typical exchange between a client and a Web application might involve several requests. For example, the Web application might send the client application an HTML page. The user might enter data onto this page, click some buttons, and expect the display to change as a result so that the user can enter more data, and so on. Each request sent by the client to the Web application is separate from any other requests sent both by this client and by any other clients using the same Web application simultaneously.

A client request often requires some sort of context or state. For example, consider the following common scenario. The user can browse goods for sale by using a Web application. The user might want to buy several items and places each one in a virtual shopping cart. A useful feature of such a Web application is the ability to display the current contents of the shopping cart. Where should the contents of the shopping cart (the client’s state) be held? If this information is held on the Web server, the Web server must be able to piece together the different HTTP requests and determine which requests come from one client and which come from others. This is feasible but might require additional processing to reconcile client requests against state information, and, of course, it would require some sort of database to persist that state information between client requests. A complication with this technique is that the Web server has no guarantee, after the state information has been preserved, that

the client will submit another request that uses or removes the information. If the Web server saved every bit of state information for every client that accessed it, it would need a very big database indeed!

An alternative strategy is to store state information on the client machine. The Cookie Protocol was developed so that Web servers can cache information in cookies (small files) on

the client computer. The disadvantage of this approach is that the application has to arrange for the data in the cookie to be transmitted over the Web as part of every HTTP request so that the Web server can access it. The application also has to ensure that cookies are of a limited size. Perhaps the most significant drawback of cookies is that users can disable them and prevent the Web browser from storing them on user computers, causing the Web application to lose all of its state information.

Understanding ASP.NET

From the discussion in the preceding section, you can see that a framework for building and running Web applications has a number of items that it should address. It must do the following:

Support HTTP

Manage client state efficiently

Provide tools allowing for the easy development of Web applications

Generate applications that can be accessed from any browser that supports HTML

Be responsive and scalable

Microsoft originally developed the Active Server Pages (ASP) model in response to many of these issues. By using ASP, developers can embed application code in HTML pages. A Web server such as Microsoft Internet Information Services (IIS) could execute the application code and use it to generate an HTML response. However, ASP did have its problems: you had to write a lot of application code to do relatively simple things, such as display a page of data from a database; mixing application code and HTML caused readability and maintenance issues; and performance was not always what it could be because ASP pages had to interpret application code in an HTML request every time the request was submitted, even if it was the same code each time.

With the advent of the .NET Framework, Microsoft updated the ASP model and created ASP.NET. The main features of the latest release of ASP.NET include the following:

A rationalized program model using Web forms that contain presentation logic and code files that separate out the business logic. You can write code in any of the languages supported by the .NET Framework, including C#. ASP.NET Web forms are compiled and cached on the Web server to improve performance.

Server controls that support server-side events but that are rendered as HTML so that they can operate correctly in any HTML-compliant browser. Microsoft has extended many of the standard HTML controls as well so that you can manipulate them in your code.

Powerful controls for displaying, editing, and maintaining data from a database.

Options for caching client state using cookies on the client’s computer, in a special service (the ASP.NET State service) on the Web server, or in a Microsoft SQL Server database. The cache is easily programmable by using code.

Enhanced page design and layout by using Master Pages, themes, and Web Parts. You can use Master Pages to quickly provide a common layout for all Web pages in an application. Themes help you implement a consistent look and feel across the Web site, ensuring that all controls appear in the same way if required. With Web Parts, you can create modular Web pages that users can customize to their own requirements. You will use themes later in this chapter. Using Master Pages and Web Parts is outside the scope of this book.

Data source controls for binding data to Web pages. By using these new controls, you can build applications that can display and edit data quickly and easily. The data source controls can operate with a variety of data sources, such as DLINQ entity objects,

SQL Server databases, Microsoft Access databases, XML files, Web services, and other