What is ASP.NET? This may seem like a relatively simple question, but I assure you that it's not. Because ASP.NET is part of the .NET framework, it is available on any server with the framework installed. In other words, it's not an add-on anymore; ASP has become legitimate. ASP.NET is implemented in an assembly that exposes classes and objects that perform predetermined specific tasks. If you are familiar with "classic" ASP (the versions of ASP that preceded .NET), you'll find that your approach to programming in ASP.NET is somewhat different, but the concepts behind building a Web application are much the same. If you're not familiar with classic ASP, so much the better—you won't have as much information to forget!

ASP.NET programs are centralized applications hosted on one or more Web servers that respond dynamically to client requests. The responses are dynamic because ASP.NET intercepts requests for pages with specific extensions, for example .aspx or .ascx, and hands off the responsibility for answering those requests to just-in-time (JIT) compiled code files that can build a response on-the-fly. Figure 4.1 shows how ASP.NET integrates with the rest of the .NET framework.

Figure 4.1: ASP.NET integration with the .NET framework

From looking at Figure 4.1, you can see that ASP.NET deals specifically with configuration (web.config and machine.config) files, Web Services (ASMX) files, and Web Forms (ASPX) files. The server doesn't "serve" any of these file types—it returns the appropriate content type to the client. The configuration file types contain initialization and settings for a specific application or portion of an application. Another configuration file, called machine.web, contains machine-level initialization and settings. The server ignores requests for Web files, because serving them might constitute a security breach.

This book concentrates on Web Forms and Web Services. Client requests for those file types cause the server to load, parse, and execute code to return a dynamic response. For Web Forms, the response usually consists of HTML or WML. For Web Services, the server typically creates a Simple Object Access Protocol (SOAP) response. While SOAP requests are inherently stateless and can thus execute immediately, Web Forms are stateful by default. Web Forms maintain state by round-tripping user interface and other persistent values between the client and the server automatically for each request. In Figure 4.1, the dashed rectangle titled Page Framework shows the difference—a request for a Web Form can use ViewState, Session State, or Application State to maintain values between requests. It is possible (but not the default) to take advantage of ASP.NET's state maintenance architecture from a Web Service, but for performance reasons, you should generally avoid doing so.

Both Web Forms and Web Services requests can take advantage of ASP.NET's integrated security and data access through ADO.NET and can run code that uses system services to construct the response.

The major difference between a static request and a dynamic request is that a typical Web request references a static file. The server reads the file and responds with the contents of the requested file. With ASP.NET there's no such limitation. You don't have to respond with an existing file—you can respond to a request with anything you like, including dynamically created HTML, Extensible Markup Language (XML), graphics, raw text, or binary data—anything. Capability, by itself, is nothing new— you've been able to create CGI programs, JavaServer Pages, classic ASP pages, ColdFusion, and NetObjects Fusion pages for quite some time. All these technologies give you the capability to respond to an HTTP request dynamically. So what are the differences?

■ Unlike classic ASP, ASP.NET uses .NET languages. Therefore, you have access to the full power of any .NET assembly or class in exactly the same way as you do from any other Windows application written in C#. In this sense, ASP.NET is similar to early compiled CGI programs, but with CGI, a separate copy of the program had to be loaded and executed for each request. ASP.NET code exists in multithreaded JIT-compiled DLL assemblies, which can be loaded on demand. Once loaded, the ASP.NET DLLs can service multiple requests from a single in-memory copy.

■ ASP.NET supports all the .NET languages (currently C#, C++, VB.NET, and JScript, but there are well over 20 different languages in various stages of development or deployment for .NET), so you will eventually be able to write Web applications in your choice of almost any modern programming language. In addition, there are open source groups working with Intel and Hewlett-Packard to support .NET on various flavors of Unix and Linux. JavaServer Pages support only Java, but because Java now has a wide support base, that's not much of a limitation. Java Servlets are more like ASP.NET but offer little support for state maintenance, Web Services, or XML. In addition, no Java design environment competes in features and quality to Visual Studio.

■ Classic ASP supported several scripting languages, although in practice, VBScript and JScript were by far the most prevalent. Although the scripting languages you could use with classic ASP were untyped, interpreted, and not particularly powerful, you could extend ASP's basic functionality by writing DLLs in any COM-compliant language. Another ASP.NET competitor, ColdFusion, uses ColdFusion Markup Language (CFML) tags, which have a powerful but limited set of capabilities; however, you can extend CFML with custom programming in C++ or Java.

■ Microsoft was able to draw on millions of hours of developer experience with classic ASP, so in addition to huge increases in speed and power, ASP.NET provides substantial development improvements, such as seamless server-to-client debugging, automatic validation of form data, and a programming model very similar to that of a Windows application.

Was this article helpful?

0 0

Post a comment