Introduction to ASP.NET

This section aims to introduce ASP.NET by describing the platform development and usage issues. In brief, running an ASP.NET page requires far less resources than creating one. Next , the section compares ASP.NET with alternative technologies. First, we will contrast Web applications based on Web Forms with Windows applications based on Windows Forms. Second, you will learn how ASP.NET and ASP contrast with one another.

Platform Requirements and Browser Considerations

ASP.NET Web applications are for Web browsers. You view a Web form in a browser. In ASP.NET, a one-to-one correspondence exists between a Web form and a Web page. A Web form in an ASP.NET Web application project is analogous to a Windows form in a Windows application project. To create a Web form, you need an ASP.NET Web application project. To create a Web application project, you need access to Microsoft Internet Information Services (IIS) version 5 or later, which is the Web server that serves the ASP.NET Web page to a browser. Any operating system that can host IIS, such as Windows 2000 Server or Windows XP Professional, is suitable as a development platform for ASP.NET Web applications. Because ASP.NET applications depend on the .NET Framework, you of course need the .NET Framework on the Web server.

Note  

Although not absolutely necessary, many developers will find it convenient to build Web application projects with Web Forms from within Microsoft Visual Studio .NET. This book describes that approach. Visual Studio .NET provides an IDE for Web application projects that runs similarly to the one for Windows application projects.

As Access developers, the Web applications that you build are likely to have data access functionality. When performing data access in ASP.NET Web applications, you need Microsoft Data Access Components (MDAC) 2.7 or later. This requirement, as well as the requirements for the Web server, are development workstation requirements. Because ASP.NET applications run from any browser, you do not need MDAC 2.7 on a client workstation. The Web server performs the data access on behalf of an ASP.NET Web page. Then, any client can consume data on a Web form. The client does not require IIS, MDAC 2.7, or the .NET Framework. The client workstation requires only a browser that can read HTML. However, not all browsers lay out HTML the same way. In addition, selected Web form capabilities, such as data validation, can optionally take advantage of client-side scripting. Script interpreters represent another element that can vary between browsers. Even if a browser has the capacity to correctly interpret a client-side script, users can shut down their browser s script interpreter for security reasons.

Note  

A best practice guideline is to standardize on a browser for any Web application, including ASP.NET Web applications. The Visual Studio .NET documentation specifies a minimum of a Microsoft Internet Explorer 5.0 browser to enable client-side scripts. I evaluated the samples in this chapter and Chapter 11 with Internet Explorer 6.0.

Comparing Web Applications with Windows Applications

With the widespread deployment of browsers in organizations, Web solutions are growing in popularity as an alternative to Windows applications. Web applications can be accessed in an identical manner whether a user is at work or at home. All the time that users spend browsing builds their skills for navigating through your custom applications. One especially attractive advantage of a Web application over a Windows application is that the client workstation for a Web application does not require the .NET Framework. When running a Windows application, however, the client workstation must have the .NET Framework installed.

You can deploy a Windows application by distributing a project folder to a computer. It might also be necessary to copy related files that are not situated inside the project folder. For example, numerous samples throughout this book refer to the Northwind database, which is not inside a project folder. In the case of a Web application, the project folder resides on a Web server. Users do not need to load a project folder onto their computer. With Web applications, users merely browse the Web pages on the Web server.

Windows applications work with instances of objects that reside on a workstation. These object instances can provide rich interactivity and other kinds of functionality directly from a workstation. With the exception of client-side scripts, Web applications do not run on a client s workstation. Web servers typically manage user interactivity through an HTTP connection between a client workstation and a Web server. Each user interaction in a Web application requires a round-trip of a Web page from a browser to a Web server and back again to the client workstation. Client-side scripts can provide more responsive user interactivity that does not depend on a Web server. However, this limits the availability of your applications to browsers that can correctly interpret the scripts, and it requires clients to leave their script interpreter running.

Windows Forms makes the layout of controls easy. For example, you can use drag-and-drop techniques to populate a Windows Form class instance with controls. This kind of layout makes it easy to arrange controls by their vertical and horizontal displacements from the form borders. Web Forms can offer this kind of design convenience if you use the GridLayout setting for the pageLayout property. However, doing so restricts the range of browsers that can interpret the layout of controls on a page. Web Forms also offers a layout style for controls that works similarly to the text in a word processor. The pageLayout setting name for this style is FlowLayout . In this page layout mode, controls and text appear from left to right and from top to bottom. With the FlowLayout setting, you cannot drag controls to an absolute position on a Web page. FlowLayout mode is the classic HTML formatting style that is widely interpreted by many browsers.

A Web page is stateless in round-trips between a browser and a server. That is, the Web server does not recall anything about the state of a page from one round-trip to the next. The stateless nature of Web pages helps Web servers scale to large numbers of sessions. However, Web applications often benefit from persisting some information about the state of a page. ASP.NET introduces a couple of innovations and takes advantage of prior ASP features to facilitate tracking the state of a page. The new ViewState property for a page enables a server to restore control property settings for a page automatically. With ASP, it is necessary to programmatically restore control property settings. You can use the Session state variables to store values within a user session so that a page from a user can access the variable values between round-trips to a user. Application state variables enable you to persist values that can be shared across all the users of an application. Because Windows applications run on a workstation, they do not require state management tools between round-trips to a server.

Contrasting ASP.NET with ASP

ASP.NET builds on the great success of ASP as a Web development tool. As you might know, ASP is the object model for programming IIS. ASP developers typically program the server using either VBScript or JScript. VBScript is somewhat similar to classic Visual Basic or Visual Basic for Applications (VBA). In addition, ASP permits ”and sometimes requires ”the intermixing of script code such as VBScript with HTML content and page layout code. As a result, the script code could be difficult to design and debug because it is not isolated in an environment of its own. Finally, IIS interprets VBScript. This need to interpret the script code for each page slows down the process of presenting a page in a browser.

ASP.NET introduces innovations to address each of the three topics mentioned in the preceding paragraph. First, you can program ASP.NET Web applications with Visual Basic .NET. Notice that I did not say JScript, or even VBScript. By allowing developers to use the same language for Web applications as for Windows applications, ASP.NET lowers the barriers to creating Web applications. Second, ASP.NET introduces a code-behind Web page development paradigm. This model is the same one used in Windows applications that support a code-behind Windows form. This feature is particularly important because it separates the Visual Basic .NET code for a Web page from the HTML layout code for the page. Third, and most important for performance, ASP.NET Web pages run from compiled versions. As with Windows applications, the code implementing a feature is compiled by default only when a user first invokes the feature. Although this can lead to a slightly longer pause when some code is initially compiled (as opposed to interpreted), the compiled code runs substantially faster than the interpreted code on its second use and subsequent uses.

Two more noteworthy points about ASP.NET and ASP relate to the file type each uses for a Web page and your ability to run ASP and ASP.NET pages concurrently. ASP.NET pages have an .aspx file extension as opposed to the familiar .asp extension for ASP pages. This distinction makes it easy to identify which type of page your application uses. The other important consideration is that you can run ASP and ASP.NET Web pages concurrently on a single IIS version 5 or later server. This means that you do not have to re-architect old solutions to start benefiting immediately from the adoption of ASP.NET technology. You can mix and match ASP.NET pages with legacy ASP pages in the same application. Just start adding new functionality with ASP.NET to an application originally created with ASP.

 


Programming Microsoft Visual Basic. NET for Microsoft Access Databases
Programming Microsoft Visual Basic .NET for Microsoft Access Databases (Pro Developer)
ISBN: 0735618194
EAN: 2147483647
Year: 2006
Pages: 111
Authors: Rick Dobson

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net