ASP开发准则是什么

ASP 作为 Web 应用架构中的关键桥梁：连接客户端与业务组件

尽管许多基于 ASP 的网站并未采用组件化设计，但本文的核心视角是将 ASP 定位为连接互联网客户端与后端业务组件的核心枢纽。明确这一角色，对于构建清晰、可维护的架构至关重要。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

ASP 与组件的职责边界划分

ASP 最核心的任务之一，是在服务器端动态生成最终呈现给用户的 HTML 或 XML 页面。因此，我们的讨论将主要围绕这一核心场景展开。一个常见的问题是：既然 ASP 页面在服务器端运行，它是否应被视为业务逻辑层的一部分？

从组件化架构的设计原则来看，答案通常是否定的。虽然 ASP 确实在服务器端执行，甚至可能与应用程序服务器部署在同一物理环境中，但这并不自动赋予其承载核心业务逻辑的职责。清晰地界定这一边界，将为未来带来巨大收益——无论是用户界面技术的升级换代，还是需要集成更多 B2B 解决方案时，清晰的层次分离都将使系统更具适应性和扩展性。

那么，如何具体划分业务逻辑层与表示层呢？以下是一些关键准则：

首先，必须将用户界面相关的代码与核心业务逻辑彻底分离。这意味着，那些与 UI 紧密耦合的代码（例如调用了 ASP 内部对象的 COM+ 组件），应当与纯粹的业务逻辑代码明确区分，并最好封装到不同的动态链接库（DLL）中。

其次，事务管理应尽量避免在 ASP 页面中直接处理。虽然在简单场景下，直接在 ASP 脚本中控制事务显得方便快捷，但一旦引入多层组件架构，情况就会变得复杂。业务组件不应依赖于客户端层（如 ASP）来管理其自身的事务边界和业务语义。

最后，关于性能的一个重要建议：凡是使用了 Request、Response 等 ASP 内部对象的表示层组件，必须部署在与 Web 服务器（IIS）相同的机器上，甚至最好在同一进程内。如果将这些组件部署到远程服务器，所有对内部对象的调用都将转变为低效的跨进程或跨机器回调，由 COM+ 服务器反向调用 IIS 客户端，这会显著降低性能并增加安全配置的复杂性。此类组件的正确部署方式，是将其标记为“库激活”模式的 COM+ 应用程序。

既然 ASP 运行在服务器端，它就必须遵循服务器端应用程序关于共享资源的使用规范，始终将系统的可伸缩性置于重要位置。具体而言：

应尽量避免在 Session（会话）中存储用户专属的状态信息。

尽可能保持 ASP 页面的无状态特性，从而为资源（如数据库连接、对象实例）池化创造条件。

实践指导：如何判断代码归属

当难以判断一段代码应属于业务逻辑层还是表示层时，可以尝试一个简单的思维实验：“如果将来我的前端从 ASP 网页更换为按键式电话交互界面，这段代码还能被复用吗？”如果答案是肯定的，那么它很可能属于业务逻辑层或通用的 UI 辅助代码。

反之，如果更换客户端后，这段代码就完全失去作用，或者它纯粹是为了构建特定用户界面而存在的“粘合剂”，那么它无疑属于表示服务层。这类代码应保留在 ASP 页面内，或封装在那些有权访问 ASP 内部对象的辅助组件中，而不应侵入到纯粹的业务对象组件里。

深入理解：桌面客户端与 ASP 客户端的本质差异

ASP 作为一种特殊的组件客户端，与传统的单线程 Windows 桌面应用程序存在根本性区别。主要差异体现在以下几个方面：

线程模型：ASP 本身是一个多线程客户端环境。这意味着大量并发请求可以同时被处理，不同用户可能在完全相同的时刻请求不同的 ASP 页面。因此，你编写的组件绝不能假设自己是系统中唯一的活跃实例。一个需要避免的常见反模式是将对象实例存储在 ASP 的 Session 或 Application 变量中，这极易引发难以预料的并发问题和性能瓶颈。

安全上下文：ASP 由 IIS 5.0 宿主执行，并可配置低、中、高三种进程隔离级别。不同的 Web 站点可以设置各异的安全策略，例如是否允许匿名访问、采用何种身份验证方式等。这些设置的组合会创造出多样化的运行环境，最终你的组件可能会在不同的 Windows 用户账户上下文中执行。

用户规模的弹性伸缩：这并非技术限制，而是 Web 应用程序天然特性带来的挑战与机遇。传统桌面应用的用户增长依赖于有计划的分发和安装。而 ASP 应用一旦部署，即可轻松地向整个组织乃至全球的合作伙伴和客户开放。理论上，一封包含网站链接的邮件就可能使访问量激增数倍。你的应用程序架构是否为此做好了准备？要获得确切的答案，唯一可靠的方法是对网站进行充分的负载测试和压力测试，以获取真实的性能基准和容量规划数据。

那么，在 ASP 页面中应如何正确使用 Visual Basic 创建的组件对象呢？核心原则是：在单个页面的请求生命周期内创建和销毁对象。

换言之，应尽可能保持 ASP 页面的无状态性。仅在绝对必要时，才利用 Session 或 Application 变量来存储少量的临时状态数据。需要特别警惕的是，绝对不要将对象引用本身存入 Session 或 Application。这样做会将特定的 ASP 工作线程与某个用户会话永久绑定，彻底破坏应用程序的可伸缩性——可能导致 Web 服务器仅能勉强支撑几十个并发用户。如果确实需要在 Session 或 Application 中持久化信息，请存储纯数据（如字符串、数字），而非承载了逻辑和状态的对象实例。

当然，还存在许多其他值得遵循的最佳实践。我们推荐您阅读 MSDN Voices 上 J. D. Meier 的专栏“Servin' it Up”。该专栏包含了大量深入的技术细节、实战经验和技巧，对于构建高性能、高可用的 ASP 与组件化应用程序极具参考价值。

关键警示：切勿在会话或应用程序变量中存储 VB 对象引用

所有由 Visual Basic 6.0 创建的组件默认都是“单元线程”（STA）模型。这意味着，一个对象在哪个线程中被创建，对该对象的所有方法调用就必须由哪个线程来执行。如果多个线程（来自并发访问的不同用户）试图访问同一个 STA 对象实例，调用将会被序列化（排队等待），极易成为整个应用程序的性能瓶颈。

更进一步，如果在 Session 作用域内存储通过 Server.CreateObject 创建的 STA 对象，实际上就将执行该会话的特定线程与当前用户锁定了。这将直接把应用程序的最大并发用户数限制在“20 x N”（其中 N 为服务器处理器核心数量）这一默认的线程池上限上，严重制约扩展能力。

操作方式与解决方案

如果你遵循了创建无状态业务对象的建议，那么就没有必要为了“复用”而存储对象引用，更不应该将其放入 Application 作用域。每个客户端请求都可以独立地创建、使用并随后释放其自己的对象实例。由于对象本身不保存与会话相关的状态，也就没有必要在 Session 中持有它们。

因此，推荐的模式是保持业务对象无状态。当需要数据时，让对象直接访问数据库、文件系统或其他外部存储（如 Cookies、LDAP 目录）。

如果确实需要利用 Session 或 Application 来跨请求存储数据，请牢记：存储的应该是数据值本身，而不是封装了数据处理逻辑的活对象。你可以设计一个专门的辅助类，来封装对这些存储在 Session/Application 中的值的访问、验证和操作逻辑。

探索 IIS 5.0 的新特性

Internet Information Services 5.0 引入了多项旨在提升 ASP 性能、可靠性和管理能力的新功能。关于这些改进的详尽说明，J.D. Meier 在 MSDN 上的文章《沿用 IIS 5.0 中的 ASP》进行了全面而深入的阐述，是深入学习相关知识的优秀资源。

以上便是关于 ASP 高效开发与架构设计的一些核心准则。深入理解并践行这些原则，对于构建健壮、高性能且易于扩展的 ASP 应用程序具有不可估量的价值。