Programming Microsoft .NET : Web Forms
From Programming Microsoft .NET. Copyright 2002, Jeff Prosise. Reproduced by permission of Microsoft Press. All rights reserved.
Authors note: The following is extracted from the book Programming Microsoft .NET by Jeff Prosise (Microsoft Press, 2002, ISBN: 0-7356-1376-1) The book teaches readers how to take advantage of the .NET Framework. It covers the key programming models embodied in the .NET Framework, including Windows forms, Web forms, and XML Web services.
In recent years, the cutting edge of software development has shifted from traditional "fat client" apps to Web apps. The integration of back-end systems and seamless data sharing, once the holy grail of corporate IT departments, have given way to concerns over lower total cost of ownership (TCO), zero-footprint installs, and the ability to run applications from anywhere an Internet connection is available. The number one challenge that confronts developers today? "Make this software run on the Web." Unfortunately, Web programming isn't easy. Writing applications like Microsoft Word and Microsoft Excel is a well understood art form. Writing applications like eBay and Amazon.com is not. To make matters worse, Web development today is practiced with first-generation tools and technologies that have more in common with 1960s-era Dartmouth BASIC than the modern platforms and development environments that developers have become accustomed to.
Microsoft's answer to the sordid state of Web programming today is a second-generation programming model called Web Forms. The Web Forms model is part of ASP.NET, which in turn is part of the Microsoft .NET Framework. Just as Active Server Pages (ASP) revolutionized Web programming in the 1990s with an easy-to-use model for dynamically generating HTML on Web servers, ASP.NET advances the state of the art in Web programming by introducing reusable server controls that render HTML to browser clients and fire events that can be processed by server-side scripts. That's Web Forms in a nutshell: Web pages built around controls and event handlers. If the concept is alluring, the implementation is downright brilliant. Once you learn to build Web apps the Web Forms way, you'll never want to build them any other way again.
This chapter introduces the Web Forms programming model by describing how to build Web forms both with and without Visual Studio .NET. First you'll nail down the basics by building Web forms by hand. Then you'll switch to Visual Studio .NET and experience rapid application development (RAD), Internet-style. Along the way, you'll be introduced to important Web forms programming techniques such as code-behind and dynamic control initialization.
Before you begin, it's worth noting what software you need to run this chapter's sample programs. First and foremost, you need the .NET Framework. Second, you need Microsoft Internet Information Services (IIS), which is Microsoft's Web server software. Finally, you need ASP.NET. ASP.NET is automatically installed when you install the .NET Framework SDK on a platform that supports ASP.NET. Currently those platforms include Windows 2000 and Windows XP. Be sure to install IIS before you install the Framework SDK, or you'll have to go back and install ASP.NET separately.
Web Application Primer
The most proficient developers are those who possess an intimate understanding of the platforms they program and the tools they use to program them. Because it's difficult to understand how Web forms work if you lack a more general understanding of Web applications and the protocols that drive them, the next several sections provide a working introduction to the operation of Web apps. They're for developers who have little or no Web programming experience. If you're already familiar with HTTP, HTML forms, and other Web-related technologies, feel free to skip ahead to the section entitled "Your First Web Form." If, however, Web apps are a new frontier for you, you'll find the following discussion helpful in building an in-depth understanding of the Web Forms programming model.
Hypertext Transfer Protocol
The Hypertext Transfer Protocol, better known as HTTP, is the protocol that drives the World Wide Web and therefore the one that underlies all Web applications. Invented by Tim Berners-Lee ("father of the Web") and documented in RFC 2068, which is available online at www.w3.org/Protocols/rfc2068/rfc2068, HTTP is arguably the most important network protocol ever invented, with the notable exception of TCP/IP.
HTTP defines how Web browsers and Web servers communicate with each other. It's entirely text based, and it's typically transmitted over TCP connections linking Web browsers to Web servers. Suppose the following HTML file is deployed on a Web server, that its name is Simple.html, and that its URL is www.wintellect.com/simple.html:
If a user types http://www.wintellect.com/simple.html into Internet Explorer's address bar, Internet Explorer (IE) uses the Internet's Domain Name System (DNS) to convert www.wintellect.com into an IP address (for example, 220.127.116.11). Then IE opens a socket connection to the server at that address using a well-known port number (port 80) and transmits an HTTP request similar to this one:
GET /simple.html HTTP/1.1Accept: */*Accept-Language: en-usAccept-Encoding: gzip, deflateIf-Modified-Since: Wed, 24 Oct 2001 14:12:36 GMTIf-None-Match: "50b0d3ee955cc11:a78"User-Agent: Mozilla/4.0.(compatible; MSIE.6.0; Windows NT 5.1)Host: www.wintellect.comConnection: Keep-Alive[blank line]
The first line of the request is called the start line. It consists of a method name (GET), the name of the resource being requested (/simple.html), and an HTTP version number (1.1). GET is one of seven methods defined in HTTP 1.1; it requests a resource from a Web server. The next eight lines make up the message header. Each line, or header, contains additional information about the request, including information about the browser that originated the request (User-Agent). A blank line (a simple carriage return/line feed pair) marks the end of the message header and also the end of the request.
How does the Web server respond to the GET command? Assuming /simple.html is a valid resource identifier and security settings don't prevent the file from being returned, the server transmits an HTTP response like this one:
HTTP/1.1 200 OKServer: Microsoft-IIS/5.0Date: Wed, 24 Oct 2001 14:12:37 GMTContent-Type: text/htmlAccept-Ranges: bytesLast-Modified: Wed, 24 Oct 2001 14:00:53 GMTETag: "d02acf81975cc11:a78"Content-Length: 46<html><body>Hello, world</body></html>
Upon receiving the response, the browser parses the HTML returned by the Web server and displays the resulting Web page. The Content-Type header identifies the returned data as HTML, while Content-Length tells the browser how much HTML was returned. The "200" in the first line of the response is an HTTP status code signifying that the server fulfilled the browser's request. The HTTP specification defines about 40 different status codes, including the infamous 401 ("Unauthorized") code indicating that the user isn't authorized to view this resource.
Conversations such as these form the backbone for communications over the Web. As you surf the Web by typing URLs and clicking hyperlinks, your browser issues one GET command after another. Tools such as NetMon-the network packet-sniffing utility that comes with server editions of Windows-let you spy on the HTTP traffic flying back and forth. You don't have to be an HTTP guru to write ASP.NET applications, but a knowledge of basic HTTP semantics and a familiarity with commonly used request and response headers are a big help in understanding the ASP.NET object model.<%2 6E
Page 1 of 4