“Active Server Page (ASP)”应用程序的成功常常取决于对体系结构和设计这两方面的取舍。考虑到 ASP 技术的范围之广和当前应用程序固有的复杂性，这种取舍是非常困难的。本文中，我将为您提供一些特定的指导方针，以助您成功开发基于 ASP 的应用程序。
从过去成功的开发模式经验中，我们总结出以下原则。
我已将指导方针整理成一组开发原则。在评估解决方案和技术时，可以应用以下原则帮助您做出决策。以下原则是我长期以来从成功的开发模式所得的经验积累。
原则 1：采用标准方法建立命名约定并使目录结构标准化，可以帮助您大大提高 ASP 应用程序的可读性和可维护性。虽然目前尚无 ASP 应用程序的正式标准，许多开发人员还是建立了一些通用方式。在此，我将与您共享一些更为通用的方式。
（本文来源于图老师网站，更多请访问http://m.tulaoshi.com/webkaifa/）因为 ASP 技术依靠脚本引擎进行工作，而且脚本具有类型不严密的天性，命名约定也很模糊。在类型非常严密的语言中，变量将按照它的实际类型进行声明。在使用 ASP 技术时，通常按照处理变量的方式（而不是其实际数据类型）在 ASP 代码中声明变量。例如，在使用“Visual Basic(R) Scripting Edition (VBScript)”时，尽管所有的 VBScript 变量都是 Variant，你还是会将成功标志声明为 bSuccess（b 代表布尔型），而不是 vSuccess（v 代表 Variant）。
下表是一些通行的命名约定。
变量前缀：
数据库对象的变量前缀：
范围及前缀的用法：
Knowledge Base (KB) 中的一篇文章“Q110264 INFO: Microsoft Consulting Services Naming Conventions for Visual Basic”（英文）对命名约定提供了真知灼见。
尽可能采用目录结构为您的各个应用程序部件提供始终如一的位置。您应用程序的实际目录结构当然由您自己决定，但通常是将图像、文档、include 文件和组件分别放置在单独的目录中。以下是简单 ASP 应用程序目录结构示例。
目录结构示例：
SimpleAspApp Docs Images Includes
一个好的目录结构允许您有选择地应用 NTFS 权限。您还可以从 ASP 应用程序内部使用相对路径。例如，可以使用以下代码，从位于 SimpleAspApp 目录的 default.asp 页，引用 Includes 目录中的 include 文件 top.asp：
./includes/top.asp
注意我的 include 文件的扩展名是 .asp，而不是 .inc。这样做是出于安全方面的考虑，而且使用 .asp 扩展名（而不是 .inc），还能够在 Visual InterDev(R) 中使用彩色编码。
有关结构化 ASP 应用程序的其他一些提示和技巧，请参阅文章“ASP Conventions”（英文）。
原则 2：设计为在服务下运行ASP 将在服务下运行。设计 ASP 应用程序时，您马上会面临在桌面应用程序中不会遇到的安全环境和线程问题。在桌面环境中，通常只处理作为交互式用户运行的单线程执行，而且有权访问当前的桌面系统。在“Internet 信息服务 (IIS)”中，模拟不同用户环境的多个客户机线程调用您的应用程序，而且您的应用程序被限于“系统”桌面。
这对您来说意味着什么？请学习 IIS 的安全模式。还要提醒您：仅因为某些东西能在 Visual Basic IDE 下能够正常运行，并不意味着它就能在 ASP 技术中安全运行。Visual Basic IDE 并没有准确地模拟运行时环境。常见的设计错误包括：在 ASP 技术中使用需要用户界面的 .OCX 控件，使用对线程来说不安全的组件，和使用要求特殊的用户上下文的组件。要避免的一个最简单的问题，就是从应用程序中试图访问 HKEY_CURRENT_USER (HKCU) 注册表项（例如，不要调用 Visual Basic 的 GetSetting 和 SaveSetting 函数，它们都依赖于 HKCU）。同样，不要出现需要用户进行人机交互的消息框或其他对话框。
以下文章是有关 ASP 技术中的安全和验证问题的相当不错的入门读物：
“Authentication and Security for Internet Developers”（英文） “Q172925 INFO: Security Issues with Objects in ASP and ISAPI Extensions”（英文） 原则 3：封装商务逻辑ASP 技术通过生成 HTML 输出提供了表示服务。简而言之，它会生成用户界面。您需要将商务逻辑从 ASP 表示脚本中分隔开来。即使您不使用 COM 组件将商务逻辑从 ASP 代码中分隔开来，至少也要将商务逻辑分隔到函数和 include 文件中，以提高可维护性、可读性和可重用性。在需要排除故障和隔离问题时，您还能体会模块化设计方法的好处。
调用脚本内部调用函数和方法，可避免代码乱作一团，并能在 ASP 应用程序中添加结构。下面举例说明从 ASP 代码中，将逻辑分离到方法调用中：
lt;% Main() MyBizMethod() ... Sub Main() GetData() DisplayData() End Sub%
在使用包含 ASP 功能的技术时，可以应用这一原则。下面举一个使用 Visual Basic WebClass 时的例子，说明如何使用这一原则：
因为 WebClass 本身引用 ASP 代码生成 HTML，所以您不要将商务逻辑直接置于 WebClass 内。因为这是您的表示层，不在 MTS/COM+ 下直接运行 WebClass。 从 WebClass，可以调用能运行在 MTS/COM+ 中的单独商务组件。 您可以决定创建自己的、具有对 ASP 引用的 COM 组件，而不是依赖于 WebClass 框架结构和额外的 WebClass 运行时开销 — 您也可以使用 ASP 脚本直接将商务组件自动化。 原则 4：尽晚获取资源，尽早释放资源常见的问题是，从桌面系统到服务器的过渡。许多具有桌面系统背景的开发人员从来没有为服务器的一些问题和资源共享担心过。在传统的桌面应用程序中，连接到服务器是个耗时的过程。为了改善用户的体验，通常采用尽早获取资源和推迟释放资源的方法。例如，许多应用程序会在它的整个运行时间内始终连接着数据库。
这种方式在传统的桌面应用程序中能够正常工作其原因是用户数量非常明确，容易加以控制，并且后端与前端紧密连接。然而，对于当前的 Web 应用程序，这种方式已经不可行了，其原因是有限的服务器资源将面对越来越多的用户。为了使您的应用程序能够应付用户的增加，您需要尽晚获取资源，尽早释放资源。
共用有助于增加这一方式的有效性。通过共用，多个用户能够共享资源，而且等待时间最少，对服务器的影响也最小。例如，在处理数据库时，ODBC 连接共用和 OLEDB 资源共用可以实现从共用池中选择连接，最大程度地减少连接数据库的开销。
有关共用 ADO 的详细信息，请参阅“Pooling in Microsoft Data Access Components”（英文）。
（本文来源于图老师网站，更多请访问http://m.tulaoshi.com/webkaifa/）原则 5：使用数据库维护复杂的状态尽管 HTTP 协议是无状态的，ASP 开发人员还是会经常使用 ASP 功能内置的状态保持机制。例如，使用 ASP 技术内置的 Application 对象，开发人员所保存的资源能够为应用程序的所有用户共享。通过使用 ASP 内置的 Session 对象，开发人员只为单个用户保存资源。
尽管听起来在 ASP 技术的 Session 对象中保存信息是一个非常方便的保持状态的方式，然而这一方式付出的代价太大，而且它也可能成为对可伸缩性的最大的限制因素之一。应用程序的可伸缩性本质上是随着用户数目的增长能够继续保持其性能的能力。而对于每一用户，在会话超时或被放弃之前，Session 对象都会消耗服务器的资源。会话还会将您捆绑到一台服务器上，从而限制您利用 Web 集群的功能。请尽可能不要使用 ASP Session 对象进行状态管理。如果您完全没有使用会话，您就可以禁用 Web 应用程序的 Session 状态（请参阅 IIS 文档）。否则，您可以使用下述语句，针对每一页禁用 Session 状态：
%@ENABLESESSIONSTATE=False %
对于一些简单的数据，您可以使用 QueryString cookie 或隐藏的窗体域保持 ASP 请求间的状态。然后，对于更为复杂的信息，通常推荐您使用数据库。一般所采用的方式是生成某一特有的标识符，然后发送到每一个发出请求的客户机，并保存为隐藏的窗体域。在随后的请求中，这一特有的标识符被用于在数据库中查找与该用户相关的状态信息。这一方式提供了更高的可伸缩性和更为简洁明了的代码。
有关使用 QueryString cookie 和隐藏的窗体域的详细信息，请参阅“Q175167 HOWTO: Persisting Values Without Sessions”（英文）。
原则 6：使用 Server.CreateObject 创建对象在创建 ASP 技术的对象时，您可以选择 OBJECT 标记、Server.CreateObject 和 CreateObject 三种方式。每项技术的行为略有不同。尽管在 IIS 4.0 中，使用 OBJECT 标记或 CreateObject 比 Server.CreateObject 略具性能优势，我们一般还是推荐使用 Server.CreateObject， 以便于 ASP 应用程序认知您的对象。（注意在 IIS 5.0 中，前两项与 Server.CreateObject 相比，已经没有性能优势。）
OBJECT 标记仅在调用第一个方法时才会创建组件，因此能够节省资源。Server.CreateObject 使用 ASP 技术内置的 Server 对象创建组件。实质上，它只是执行了 CoCreateInstance，但是 ASP 却能够认知这一对象。同时，还将调用 ASP 技术的传统的 OnStartPage 和 OnEndPage。（注意最好在 IIS 4.0 或者更高版本中使用 ObjectContext）。如果您只是使用 CreateObject，您将越过 ASP 技术而直接使用 Scripting 引擎。
以下是一个可能出现的例外情况：当您通过防火墙进行调用时，您可能需要调用 CreateObject 而不是 Server.CreateObject。详细信息，请参阅“Q193230 - PRB: Server.CreateObject Fails when Object is Behind Firewall”（英文）。
原则 7：提供丰富的疑难解答信息确保在您所有的 ASP 应用程序中都包含了错误处理过程。而且，确保您提供了有用的诊断信息。我还没有碰到有哪个人抱怨错误信息太具有说明性了。请确保在错误日志中包含以下信息：
用户上下文（如果您正在使用组件，您可以调用 GetUserName） 线程 ID（在组件中，可以调用 GetCurrentThreadId） 时间 完整的错误信息（包括编号、
