An Overview of ASP.NET

Since the advent of using server-side code to produce results on a Web page, developers have looked at ways of making it easier, both for the end user and the developer. Consider the following business case: Your current Web site allows users to access it, get basic contact information, and call you if they want to order anything. (Not all that long ago, this limited capability was what most e-commerce sites offered.) The problem is, you want to allow users at least to see what you have to sell; based on recent business, that could be a lot of users.

To allow for this kind of interaction with such a Web site, many different scripting languages and technologies began to emerge in the early days of e-commerce. One of these technologies was Microsoft's Active Server Pages (ASP). It provided a means by which code that was embedded within a Web page could be executed as the Web server processed the request. From a developer's point of view, this capability was revolutionary; at last, the developer could enhance the user's experience by using VBScript that executed on the server. This type of interaction began to overtake the approach that had everything happening in the browser (as with JavaScript and ActiveX). In addition, VBScript expanded to the point where it could call compiled COM objects on the Web server and incorporate their functionality in a Web page. From that stage, Microsoft Transaction Server, now known as Component Services, emerged.

So what happens when you mix the best parts of server-side coding, client-side scripting, and code compilation for security and scalability? You get ASP.NET. The resulting ASP.NET, or ASPX, allows for the use of rich server-based coding in the full language that a developer is used to. Right now, support for C#, Visual Basic, C++, FoxPro, Perl, COBOL, and FORTRAN have all been made available to the Common Language Runtime (CLR) and can be used in special Web pages to enhanced the user's experience.

In addition, all ASPX files are compiled and cached. That is, once the page has been requested, it is compiled into a temporary .dll file that actually does all the work on future requests. The results are faster performance and less latency.

HTML Controls Versus Server Controls

Another new concept presented in ASP.NET is that of the server control. A server control can be coded into a Web page, yet every event and property associated with that control is executed at the Web server. Server controls are analogous to HTML controls but have several advantages.

Any developer who has ever created a Web page that contains a form has seen an HTML control. Starting with the FORM element, different types of INPUT elements (such as text, select, and checkboxes) are created. A simple example is

 <input type="text" name="txtName" value="">  

These INPUT elements are still quite available in ASP.NET, but any attempt to validate their contents requires either client-side scripting or server-side processing. The problem in our fictitious business case is that we don't want to create browser incompatibilities. With client-side script, there is always a chance that either the browser doesn't support the script or that scripting has been disabled in the user's browser for security reasons. So how can we control this environment without using client-side scripting? Server controls are the answer.

Another interesting point of contrast to server controls is ActiveX. Its controls attempted to bring fat-client technology to the Web browser. For more reasons than we can list here, the use of ActiveX controls embedded in Web pages served over the Internet was a bad idea, and the use of such technology has waned. Enter the server control. A server control contains no direct code that executes on the client; rather, the client receives only HTML, and all interactions are processed by "posting back" the information to the Web server. The DataGrid, which we cover later in this chapter, is an excellent example of a server control, as the control simply takes a dataset, processes it, and produces an HTML table that can be viewed in any browser. Yet it doesn't look like the standard HTML table with a lot of data in it.

Note

Server controls can be created by using the Visual Studio IDE.

To complete our comparison of HTML and server controls, we use the following ASP.NET code snippet to represent how a server-side textbox control may look:

 <asp:TextBox  runat="server" text=""></asp:TextBox>  

The intent of this server control is exactly the same as the HTML control snippet shown earlier. The only difference is that this textbox is processed at the server.

Additional Highlights of ASP.NET

Entire books have been written on just the new functionality within ASP.NET and how to use it. What follows are a couple of items that, in addition to server-side controls, have become the most used real-world approaches to date.

The first item is the IsPostBack functionality. When an ASPX file also known as a WebForm is created, the default behavior is for the page to submit any data on the form to itself. Because you don't want a user to get error messages for missing data values on a page she hasn't seen yet, the IsPostBack option comes into play. IsPostBack tells you whether the page has been submitted to itself or is being requested for the first time. The following code snippet shows how simple this option is to use:

 If Page.IsPostBack() Then  'Handle the information End If 

Of course, you can still have an ASPX or HTML file that also submits to another ASPX file. This option allows you to maintain a single file that contains the desired functionality. If you want the user to be sent to another page once all the data has been validated and corrected, Response.Redirect still works great.

Another noteworthy feature of ASP.NET is the means by which you can deploy an application. Basically, you copy all the files from one machine to another. Of course, there are a few other things to consider. The first is that the new virtual directory in Internet Information Server (IIS) must be configured as an application. To do that, open the IIS MMC applet, right-click on the desired directory and select Properties, which displays the Properties dialog; then select the Virtual Directory or the Home Directory tab, depending on your operating system. In the Application Settings area, if the virtual directory isn't configured as an application, you'll see a Create button. If the virtual directory is already configured as an application, don't change anything just click on Cancel to close the dialog. After you click on Create, click on OK to close the dialog. Your virtual directory is now configured as an application.

Any server to which you copy an application need not have Visual Studio installed. Only the .NET Framework, which is downloadable for free from Microsoft's Web site, http://www.microsoft.com, is required.