ASP.NET Web Applications

ASP.NET applications, at their simplest, are much like classic ASP applications. The elements of a simple ASP.NET application are

• A virtual directory in IIS, configured as an application root, to hold the files that make up the application and to control access to the files.

• One or more .aspx files.

• A Global.asax file (analogous to the Global.asa file in classic ASP) to deal with Session and Application startup and clean-up logic. This file is optional.

• A Web.config file used to store configuration settings. This file is optional, and is new for ASP.NET.

For Visual Studio .NET users, the good news is that all of the preceding files are created for you when you create a new Web application project.

ASP.NET Web Forms

Web Forms are an important part of any ASP.NET Web application. Put simply, they are ASP.NET pages that use ASP.NET Server Controls. The Web Forms programming model makes it possible (and relatively easy) to develop Web- based applications in much the same way that today’s Microsoft Visual Basic programmers develop Microsoft Windows–based applications that have a GUI.

Web Forms in Visual Studio .NET allow you to create rich, interactive applications simply by dragging and dropping controls onto a page and then writing minimal code to handle user interaction, events, and so on. In addition, the Visual Studio .NET environment lets you work on your pages either visually—using the Web Forms Designer—or textually, using the powerful Visual Studio .NET source-code editor.

You can write code in your Web Forms in one of two ways: inline in the .aspx file (as is typical of a classic ASP page), or using a code-behind module. Although it’s possible to write your application with code in the actual .aspx file and still take advantage of compiled code and the other improvements of .NET, I recommend that you get in the habit of using code-behind modules. Visual Studio .NET defaults to using code-behind for UI-specific programming logic.

Code-Behind

Code-behind is a new feature in ASP.NET that allows developers to truly separate the HTML and tag-based UI elements from the code that provides user interaction, validation, and so on. Code-behind modules offer developers a number of advantages:

• Clean separation of HTML and code Code-behind allows HTML designers and developers to do what they do best independently, thereby minimizing the possibility of messing up one another’s work (something that happens all too frequently when developing classic ASP applications).

• Easier reuse Code that isn’t interspersed with HTML in an .aspx page can be more easily reused in other projects.

• Simpler maintenance Because the code is separated from the HTML, your pages will be easier to read and maintain.

• Deployment without source code Visual Studio .NET projects using code-behind modules can be deployed as compiled code (in addition to the .aspx pages), allowing you to protect your source code. This can be very useful if you’re creating applications for clients but want to retain control of your intellectual property.

All in all, it’s worthwhile to get into the habit of using code-behind. You’ll see examples of code-behind throughout the book.

ASP.NET Web Services

Although no one would deny that Web applications created with ASP.NET (or even with classic ASP) can be very useful, one feature that has long been missing is an easy way to provide programmatic functionality over the Internet or an intranet without tying the client to a specific UI. This is where ASP.NET Web services come in.

A Web service, at its simplest, is a chunk of programming code that is accessible over the Web. Web services are based on the World Wide Web Consortium’s (W3C) SOAP specification. This allows computers on varying platforms, from Windows servers to UNIX workstations, to offer and consume programmatic services over the HTTP protocol.

ASP.NET makes it remarkably easy to implement Web services. In fact, all it takes is adding an appropriate declaration to any method you want to make available as a Web service. Visual Studio .NET makes it even easier by taking care of all the work necessary to make your Web service available to potential clients. Part IV will discuss Web services in greater detail.

ASP.NET Mobile Web Applications

Like standard ASP.NET Web applications, ASP.NET Mobile Web applications contain a number of standard elements:

• A virtual directory in IIS, configured as an application root, to hold the files that make up the application and to control access to the files.

• One or more .aspx files. Visual Studio .NET creates a single Web form by default with the name MobileWebForm1.aspx. The default Web Form contains a special <mobile:form> element, which acts as a container for mobile Web server controls (formerly part of the Microsoft Mobile Internet Toolkit). These controls allow you to design a UI for your application that automatically adapts to a wide variety of mobile devices.

• A Global.asax file to deal with Session and Application startup and clean-up logic. This file is optional.

• A Web.config file used to store configuration settings. In a Mobile Web Application project created with Visual Studio .NET, this file also contains a set of filters that help tailor page output to various mobile devices. This file is optional.

As with the ASP.NET Web Application template, Visual Studio .NET creates all of the preceding files when you create a new ASP.NET Mobile Web application project. You’ll learn more about developing ASP.NET applications for mobile devices in Chapter 8.