This tutorial will help you figure out how to write Web applications using Microsoft's most current version of its HTTP request processing framework¡ªASP.NET 2.0. Web development has come a long way since the earliest sites began popping up in the early 1990s. The world of Web development offers several different choices as far as development tools go. Over the past few years, ASP.NET has evolved to become one of the most consistent, stable, and feature-rich frameworks available for managing HTTP requests.
ASP.NET together with Visual Studio include a number of features to make your life as a Web developer easier. For example, Visual Studio starts you off with several very useful project templates from which to develop your site. Visual Studio also supports a number of development modes, including using Internet Information Services directly to test your site during development, using a built-in Web server, or developing your site over an FTP connection. The debugger in Visual Studio lets you run the site and step through the critical areas of your code to find problems. The Visual Studio designer enables effective user interface development, allowing you to drop control elements onto a canvas to see how they appear visually. These are but a few of the features built into the ASP.NET framework when paired with Visual Studio.
While ASP.NET and Visual Studio offer excellent tools for writing Web applications, Web development on the Microsoft platform hasn't always been this way. The road to ASP.NET 2.0 has been nearly a decade in the making.
Until about 1993, there were very few Web servers in the world. Most of these earliest Web servers lived at universities or other research centers. In the early 1990s, the number of Web sites available began to increase dramatically. If you used the Web back in the early 1990s, chances are you probably came across little more than some HTML pages put together by the earliest Web site pioneers or some photo collections represented by links to GIF or JPEG files. Back then, there was no Google, no Yahoo, and certainly no MSN Search. The only way you could get to someone's site was if you either knew the site's Uniform Resource Locator (URL) or were referred to it through someone else's page.
Typing a URL like this:
http://www.somesite.com
into a browser's navigation window sent your request through a maze of routers, finally appearing at a server somewhere. The earliest Web servers lived on UNIX boxes. They performed the simple job of loading the HTML file and sending it back to the requestor (perhaps a browser such as Mosaic).
The advent of the Common Gateway Interface (CGI) introduced a standard way to interface with browsers to produce interactive Web applications. While a Web server that serves up plain, static HTML documents is useful in certain contexts (for example, a hyperlinked dictionary), more complex applications require a conversation between the user and end server.
That's where CGI comes in. With the help of HTML tags representing standard GUI controls, CGI applications can respond to requests dynamically. That is, CGI applications vary their output depending upon the state within the request and the application, paving the way for widely interactive applications. For example, a CGI application can examine an incoming request and determine the user is looking for a certain piece of information (perhaps a product code). The CGI application can perform a database lookup for the product and shoot some HTML that describes the product back to the client.
When it became clear that the Web was an important aspect of information technology, Microsoft entered the fray by introducing the Internet Services API (ISAPI) and a program to listen for HTTP requests: Internet Information Services (IIS). While the first UNIX Web servers started a new process to handle each HTTP new request (in keeping with the classical UNIX model), that model is very expensive. The Microsoft Web strategy is based on DLLs. It's much faster to load a DLL to respond to an HTTP request than it is to start a whole new process.
When programming to the Microsoft platform, IIS listens to port 80 for HTTP requests. IIS handles some requests directly, while delegating other requests to specific ISAPI extension DLLs to execute the request. In other cases, IIS will map a file extension to a specific ISAPI DLL. A number of ISAPI DLLs come preinstalled with Windows. However, IIS is extensible, and you may map different extensions to any ISAPI DLL¡ªeven one you wrote. To make a Web site work using IIS and ISAPI, developers employ ISAPI DLLs. These DLLs intercept the request, decompose it, and respond by sending back something to the client (usually some HTML).
While the IIS/ISAPI platform represents a very flexible and functional way to create Web applications, it's not without its downside. Specifically, ISAPI DLLs are traditionally written in C++ and are subject to the pitfalls of C++ programming (including such foibles as de-referencing bad pointers, forgetting to free memory, and traditionally lengthy development cycles). The other problem with ISAPI DLLs is that it's becoming increasingly more difficult to find C++ programmers. Enter Active Server Pages, or classic ASP.
In an effort to make Web development more accessible on the Microsoft platform, Microsoft introduced Active Server Pages (ASP). The idea behind classic ASP is that a single ISAPI DLL named ASP.DLL interprets files with the extension ASP (for example, MYSITE.asp). ASP files include some HTML and perhaps some script code to be executed on the server. The ASP ISAPI DLL executes the script code as necessary and sends the HTML contained in the ASP file back to the client. The script code usually calls COM objects that do the dirty work (for example, looking up items in a database and tailoring the output based upon its findings) while the look and feel of the page is defined by the HTML in the ASP file.
While ASP opened the doors to a whole host of new programmers by catering to a much more widely used programming language (Visual Basic and VBScript), it wasn't the silver bullet. Among the downsides of classic ASP are:
Mixing of user interface code and programming logic
Performance issues due to IDispatch
Inconsistent means of managing state (session state and application state)
An ad-hoc security model
This isn't an exhaustive list by any means, but it highlights the most important issues with classic ASP. That's why ASP.NET exists.
Microsoft's .NET framework introduces a whole new way of programming the Microsoft platform. Microsoft developers are primarily concerned with threads and memory (that's basically the API programming model). This model carried over to all areas of development, including Web development, placing a heavy burden upon programmers.
.NET is built upon the notion of managed types. Developers writing classic Windows code (and Web code) wrote classes using C++ or Visual Basic. In many ways, types are similar to the notion of the C++ class in that types are units of state with functionality attached to them. However, the similarity ends there. Whereas it was incumbent upon the developer to manage instances of classes, types are managed completely by the .NET runtime services¡ªthe Common Language Runtime (CLR). Because the CLR takes over managing memory and threads, developers are much more at liberty to concentrate on the actual application (rather than chasing down errant pointers, memory leaks, and unexplained crashes).
ASP.NET introduces runtime services and a well-engineered class library for greatly enhancing Web development. In a way, classic ASP was sort of ¡°taped onto¡± the IIS/ISAPI architecture without any real organic thought as to how early design decisions would affect developers later on. Well, now it's later on and classic ASP.NET's warts have become fairly obvious.
ASP.NET is built from the ground up to be an extensible, feature-rich way to handle HTTP requests. ASP.NET leverages IIS in that requests for ASP.NET services are mapped to an ISAPI DLL. The DLL is named ASPNET_ISAPI.DLL. From there, processing is passed into a worker process provided by ASP.NET (ASPNET_WP.EXE in IIS 5 or W3WP.EXE in IIS 6). The fundamental request processing is handled by managed types within the worker process. Control passes between a number of classes plugged into the pipeline¡ªsome provided by Microsoft and/or third parties, and some provided by the developer. What's more, ASP.NET is built from the ground up to be a comprehensive framework for writing Web applications. All the parts of the framework execute together to handle requests. By contrast, classic ASP.NET script code had no structure to it, and code logic within applications tended to be ad hoc.
ASP.NET 1.0 and 1.1 provided a significant number of features, including:
An object-oriented framework for defining applications
Separation of user interface declarations (HTML) and application logic
Compiled code for executing application logic
Configurable session state management
Built-in data caching
Built-in content caching
A well-defined UI componentization architecture
High-level components for managing data formatting (grids, lists, text boxes)
Built-in program tracing and diagnostics
Built-in user input validation
An easy-to-use custom authentication mechanism
Solid integration with ADO.NET (the .NET database story)
Excellent support for Web Services
Zero reliance on the Component Object Model
An extensible pipeline with many places in which a request can be intercepted
ASP.NET 1.0 set the stage for many developers both moving into Web development and moving to the Microsoft Platform.
Which brings us to ASP.NET 2.0. ASP.NET 2.0 builds upon ASP.NET 1.0 and 1.1 by providing a number of new features in addition to what already existed with ASP.NET 1.0. These features include
Master Pages and Skins
Declarative databinding
Provider pattern model
New cache features
Membership controls
Personalization controls
Support for Web Parts
Programmable configuration
Administration tools
New compilation model
All the features of ASP.NET 1.0/1.1 are still there. However, these new features make ASP.NET an even more compelling platform for creating Web sites. We'll visit all these features as we tour ASP.NET 2.0.
ASP.NET 2.0 is built upon Microsoft's Common Language Runtime. In its earliest days, programming Windows involved interacting with the operating system at a very intimate level. For example, getting a Window to show up on a screen took many lines of C code. In addition, Windows included a rudimentary component technology¡ªraw Dynamic Link Libraries. Dynamic Link Libraries (DLLs) represent a necessary technology to enable composing systems dynamically¡ªthat is, to assemble applications from several disparate binary components. However, DLLs by themselves are not sufficient for composing systems reliably¡ªprimarily because it's very difficult to manage multiple versions of a component (a DLL).
During the mid 90's, the Component Object Model (COM) emerged as a way to help manage multiple versions of a component. By stipulating strict rules about how clients and components may interact, COM represented a technology sufficient for composing applications from different binary components. However, COM faced a few dead ends which became apparent as developers began building larger systems.
First, COM relied on humans following rules to get things to interoperate. For example, COM stipulates a rule that once a programmatic interface is published, it must never change. Changing a published COM interface after clients begin coding against it will almost certainly bring a system to its knees. In addition, COM relied on sometimes obtuse rules as far as managing resources. However, the coup de grace for COM was probably the disparate type systems involved. That is, COM represented many data types differently for three separate classes of developers: C++ developers, Visual Basic developers, and scripting developers. The different data type systems made it extremely inconvenient to build systems built from different languages. It could be done, but developers had to be very wary when making calls across such component boundaries.
.NET and the Common Language Runtime (the CLR) were developed to solve the dead ends appearing in COM near the end of the last century. When you choose to buy into the .NET runtime, it's like putting your code in a nice hotel room when it runs. For example, the .NET runtime loads and manages your code as it runs. Pure memory leaks are a thing of the past because the runtime collects garbage when necessary. The problem of overrunning array boundaries disappears because the .NET runtime keeps careful watch over memory and knows when anything is out of place. In addition, the .NET runtime includes a new security model making it more difficult to hack into .NET-based software. Finally, the .NET runtime introduces a new packaging and deployment model, .NET Assemblies, which helps enforce versioning components.
ASP.NET is founded on the .NET runtime. As we'll see in the following tutorials, ASP.NET runs completely under the auspices of the CLR. After IIS hands an HTTP request off to ASP.NET, it runs through the ASP.NET pipeline. The request may be intercepted at various places along the way, and you have ample opportunity to interrogate the request and modify the response before it finally leaves the ASP.NET runtime. Gone is the COM layer between the HTTP request processing machinery and a business's domain objects. Domain objects running under .NET can be linked into the request processing pipeline for high performance and tight security. In addition, because all .NET components agree upon the data types being passed between them, there are no more bizarre data conversions (as there used to be in classic ASP).
In the process of building ASP.NET applications you will be developing .NET assemblies¡ªmost of the time implicitly, but sometimes explicitly. While you'll be focusing on ASP.NET as a Web application framework, you'll develop a strong familiarity with the .NET runtime as well. Very often, the classes you use in an ASP.NET application are the same or very similar to those you'd use in a console application, a Windows application, or even a component library.
discuss this topic to forum
