Design Considerations for IIS Applications

See Also

There are several factors you should keep in mind when creating an IIS application. These include deciding on a consistent directory structure, using paths that will make your deployment work smoothly, and considering the unique navigational considerations of Web applications.

General Considerations

• Use relative URLs to images and related files. Your application and its HTML pages can be deployed onto a Web server under a different parent directory than the one on the development computer. Because of this, it is best to use relative URLs in your HTML pages rather than absolute URLs. Absolute URLs indicate the exact drive and directory in which your HTML page will expect to find any related images or other files it references. Relative URLs give the name of the file to locate and indicate its location in relation to your project directory, specifying how many directories up or down to move to find the reference.
  
  
• Anticipate your Web server directory structure. During design, think about the Web server directory structure you will use when you deploy your application, and use the same directory structure on your development machine. Your project files — including the designer, its DLL, any template files, and any additional files the templates reference (such as .gifs) — must be stored in the project directory or in subdirectories below it. For more information see "Managing your Project Files."
  
  
• Use generated URLs. Use generated URLs whenever possible to move to other webitems or pages, rather than typing a manual URL (http://www.myserver.com/mypage.htm) into your webclass templates or code. For more information, see "Specifying URLs for Webitems."
  
  
• Gather request resources with BeginRequest. Use the BeginRequest event to gather expensive server-side resources that the webclass should not hold longer than the duration of a request. Release those resources with the EndRequest event.
  
  
• Use ADO data features. When working with databases in your webclass code, use ODBC connection pooling and ADO disconnected recordsets. For more information, search the MSDN library for ActiveX Data Objects.
  
  
• Review your state management options carefully. When planning your application, it is important to read through the information on state management and choose the most appropriate method for your needs. For more information, see "State Management in IIS Applications."
  
  
• Be careful when using wcRetainInstance. When keeping a webclass alive between requests, be aware that Visual Basic creates apartment-model objects that it places into the Session objects. This causes IIS to bind the client to a particular thread. This may cause difficulties for your application. This may also be an issue if you put Visual Basic classes into the Session or Application objects. For more information, see "State Management in IIS Applications."
  
  
• Do not use HTML pages that contain forms with the GET method. If you use an HTML template file that contains forms that use the GET method, you will not be able to successfully connect events and run the application. You need to make sure that all template files you use in your webclass use the POST method for any forms.

Navigational Considerations

It is difficult to predict the exact way in which users are going to interact with a browser-based application. Unlike a forms-based application, where navigation from form to form is generally fixed, users in a browser-based application can move backward and forward at any time, can jump randomly, or can close the application without completing their current process. Because of this inherent flexibility, there are several things you should keep in mind:

• Close database transactions. Try to avoid holding open database transactions across request boundaries, because there is no guarantee that the user will return to the transaction after the initial request is made. Holding a transaction open on a database consumes expensive resources and locks a part of the database from other users. Instead, consider committing database changes at the end of every request.
  
  
• Allow for open navigation. Structure your application so that users can navigate freely among the application's webitems, rather than assuming a fixed navigation path. You can do this by including navigational buttons and other aids that allow a user to return to the starting point from any place in the application, or including other cues that help the user figure out the appropriate navigational choice from each screen.
  
  
• Anticipate re-submits. Consider how you will handle out-of-sequence navigation caused by use of the browser’s back button and history menu. This can be particularly important in the case of applications that use HTML forms. In these situations, the user might complete a transaction and then use the back button to return to a data entry form thinking they can make a correction and resubmit.
  
  
• Refill data structures when a user moves backwards. Any internal data structures you use in the application must be filled appropriately. For example, suppose your startup screen in the application asks for a user name and password, which you then store in member variables. If a user is in the middle of your application and navigates back to the startup screen, you must reset the variables to their original state.