IIS 应用程序的设计考虑

当创建一个 IIS 应用程序时，应当牢记几个因素。这些因素包括：决定一个一致的目录结构；可使您的布署工作顺利进行而使用的路径；考虑 Web 应用程序独特的漫游特性。

一般的考虑

• 对图像及相关的文件使用相对 URL。您的应用程序和它的 HTML 页面可能布署到 Web 服务器上与开发计算机不同的父目录下。因此，在您的 HTML 页面上最好使用相对 URL而不要使用绝对 URL。绝对 URL 表示确切的驱动器和目录，您的 HTML 页面期望在它上面找到任何相关的图像或它引用的其他文件。相对的 URL 给出要找文件的名字并表示它的位置与您的工程目录之间的关系，指明了如何向上或向下移动多少个目录去找到这个引用。
  
  
• 预测您的 Web 服务器目录结构。在设计期间，考虑当布署您的应用程序时将使用的有关 Web 服务器目录结构，并且在开发计算机上使用相同的目录结构。您的工程文件—包括设计器、它的 DLL、任何的模板文件和模板引用的附加文件（如.gif 文件）— 必须保存在此工程目录中或它下面的子目录中。关于详细的信息，请参阅“管理工程文件”。
  
  
• 使用生成的 URL。每当可能移动到其他的 webitem 或页面时使用生成的 URL而不是键入一个手工的URL（http://www.myserver.com/mypage.htm）到您的webclass模板或代码中。 关于详细信息，请参阅“为 Webitems 指定 URLs ”
  
  
• 用 BeginRequest 搜集请求资源。使用 BeginRequest 事件搜集 webclass 只在请求期间占有的昂贵服务器端资源。用 EndRequest 事件释放这些资源。
  
  
• 使用 ADO 数据特性。当在您的 webclass 代码中使用数据库时，使用 ODBC 连接缓冲池和 ADO 分离记录集。关于详细信息，请查找 ActiveX 数据对象的 MSDN 库。
  
  
• 仔细地检查您的状态管理选项。当规划您的应用程序时，从头到尾阅读状态管理的信息并针对需要选择您最适合的方法是非常重要的。 关于详细信息，请参阅“ IIS 应用程序的状态管理器”。
  
  
• 当使用 wcRetainInstance 时务必小心。当在请求之间保持一个 webclass 存活时，应当注意 Visual Basic 创建一个放到 Session 对象中的单元模型对象。这使得 IIS 将客户绑定到一个特别的线程上。它可能使您的应用程序产生困难。如果您将 Visual Basic 类放到 Session 或Application 对象中，这也可能是一个问题。 关于详细信息，请参阅“ IIS 应用程序的状态管理器”。
  
  
• 不要使用包含 GET 方法窗体的 HTML 页面。如果您使用一个包含 GET 方法窗体的HTML模板文件，您将不能成功地连接事件和运行应用程序。您需要确定在您的 webclass 中使用的所有模板文件对任何窗体都使用的 POST 方法。

漫游考虑

要预测用户将使用哪种确切的方式同基于浏览器的应用程序进行交互是非常困难的。和一个基于窗体的应用程序不同，在基于窗体的应用程序中，从窗体到窗体的漫游通常是固定的，而在基于浏览器的应用程序中，用户可以在任何时候向前和向后移动，也可以随机地跳动或没有完成当前的处理就关闭应用程序。由于这种固有的灵活性，有几件事情您应当记住：

• 关闭数据库的事务处理。尽量避免跨过请求的边界保持打开数据库的事务处理，因为不能保证用户在最初的请求之后会返回到该事务处理中。保持一个事务处理在数据库中打开将消耗昂贵的资源并对其他用户封锁数据库的一部分。相反，应考虑在每一个请求结束时提交数据库的更改。
  
  
• 允许开放漫游。构造您的应用程序以使用户可以在应用程序的 webitem 中自由地漫游，而不是假定一个固定的漫游路径。为此，您可以通过包括漫游按钮和其他辅助手段，以允许用户从应用程序的任何地方返回到开始点，或包括其他提示，来帮助用户从每一个屏幕中找出合适的漫游选择。
  
  
• 预先进行再提交。考虑如何处理由使用浏览器的倒退按钮和历史菜单引起的不按顺序的漫游。 在应用程序使用 HTML 窗体的情况下这是非常重要的。在这种情形中，用户可能在完成一个事务处理后使用倒退按钮返回到一个数据输入窗体再考虑作出纠错及重新提交。
  
  
• 当用户向后移动时回填数据结构。在应用程序中使用的任何内部数据结构必须被适当地填充。例如，假如您应用程序的启动屏幕请求一个用户名和密码，然后将其存储在成员变量中。假如一个用户处在您应用程序的中间部分并且向后漫游到启动屏幕，您必须将变量重新设置成原来的状态。