ASP.NET Up Close
This chapter is from the book
This chapter is from the book
This chapter is from the book
In the last six chapters, you have been introduced to a diverse C# CodeBase and some active server page (ASP) code sprinkled here and there. For example, in Chapter 4 we covered an application named Managed Synergy, primarily to show you how to apply C#. To do that, we had to throw in some ASP.NET in certain places. In this chapter (and Chapter 8), we discuss ASP.NET in more detail—what it is, how it works, and how to apply its more advanced features.
.NET is about to be released to the world at large. During the last few months of its beta period, its early adoption rate has been staggering. Judging from the feedback on the .NET lists and the size of the community that is growing up around it, .NET looks like it is going to be huge. As we have discussed so far, the .NET framework represents an implementation of several great modern software development ideas that have been a long time coming. These ideas include a Common Type System (CTS), a common runtime environment, the ability to really mix languages within a single application, and the ability to invoke methods over the Internet. These factors contribute to the new software paradigm coming down the road: people-oriented software. .NET comprises many facets, but one of the most important parts of .NET—the one that will almost certainly be a lynchpin in its success—is ASP.NET. ASP.NET ties together all three facets of people-oriented software: universalization, translation, and collaboration. Although a few of the modern Microsoft-based Web sites will probably continue using ISAPI extensions and classic ASP (and perhaps the Active Template Library server [ATL server]), most other Microsoft-based Web sites will be written using ASP.NET.
Connective Tissue
Most of us in the software industry these days agree that the computing world of the future will involve the Internet as the network of choice. How could it be any other way? The Internet is ubiquitous. The dream of the 1980s and 1990s was to get computers within a single office talking to one another. Now, local area networks (LANs) and companywide intranets are commonplace. The vision for the next decade is to get all the computers in the world talking to one another. Now that nearly everyone agrees on the protocol (Hypertext Transfer Protocol [HTTP] or HTTPS) and the bits to send across (Extensible Markup Language [XML] that is formatted using Simple Object Access Protocol [SOAP]), connecting Web sites programmatically can actually happen.
However, although the communication standards and protocols are currently being set up and agreed to, what is really going to kick the .NET vision into high gear is a decent way to implement the standards. At the heart of it all, Web sites are still going to be nodes on the Internet managing HTTP requests and responses. As developers, we need a structured way to intercept and respond to HTTP requests. This is what ASP.NET provides. ASP.NET is going to be one of the most important parts of .NET for bringing people-oriented software to life.
The Road to ASP
So that you can really understand ASP.NET, let's take a quick look at the metamorphosis the Web has gone through during the past few years. The Web really began to be popular around 1995 or so, and in that short time it has been transformed from a set of fancy marketing brochures into sites with full-fledged order-entry systems and other advanced features.
Classic ASP evolved as a way to more easily develop "dynamic" content—that is, to have the content of your Web site change at runtime. The first Web pages up on the Web were just hypertext markup language (HTML) pages that never changed—kind of like electronic brochures. People would sign on to a uniform resource locater (URL) somewhere, and their browsers would simply zoom in on some files in some directory on the remote computer. The browser on the client machine would download the HTML using HTTP and interpret it. Obviously, the next step was to make the content change based on various conditions (such as who is signed on, the content that is available at runtime, and the security context of the client). This is the origin of dynamic content.
The first dynamic Web sites were the result of the common gateway interface (CGI). CGI provides dynamic content by directly processing incoming HTTP requests and issuing responses in a custom process. The CGI process spits out customized HTML based on the requests coming in. One of the problems of CGI was the fact that each incoming HTTP request got a new process, creating a burden on the server. Creating a new process for each request was pretty expensive.
To reduce the burden of creating a new process for every request (on the Microsoft platform), Microsoft implemented a programming interface they named the Internet Services API (ISAPI). Instead of firing up a new process for each request, ISAPI fires up a new instance of an ISAPI dynamic link library (DLL), customized to spit out specific HTML. Of course, ISAPI DLLs were not the easiest things in the world to write. The next step in the evolution was ASPs (active server pages).
You can think of classic ASP as one big ISAPI DLL that Microsoft has already written for you. Classic ASP accepts and posts responses to HTTP requests. ASP mixes presentation (HTML) with scripting blocks so that you can control the content coming from an ASP page. ASP parses files with .asp extensions and does its best to emit the right kind of HTML. HTTP requests and responses are available as well-established objects you can get to easily from within the script blocks. (They are part of the component object model [COM] runtime context.)