ASP开发准则是什么

虽然许多使用 ASP 的 Web 站点根本就不用组件，但在这篇文章中假定 ASP 是 Internet 客户机和组件之间的桥梁。

话说回来，很多朋友在实际项目中可能只用ASP，不碰组件。但我们今天讨论的核心，是把ASP当作连接客户端和后台业务组件的那座关键桥梁。在这个前提下，划分清楚各自的职责就变得至关重要。

ASP和组件之间的划分服务

ASP最常见的任务，莫过于在服务器端生成最终呈现给客户的HTML或XML页面。因此，我们主要围绕这个场景来展开。这就引出一个经典的疑问：既然ASP页面跑在服务器上，它算不算业务逻辑层的一部分？

在组件化设计的思维里，答案通常是否定的。没错，ASP确实在服务器端执行，甚至可能和应用服务器部署在同一物理空间，但这并不自动让它晋升为业务逻辑的核心。明确这层界限，未来会带来巨大的回报——无论是用户界面技术迭代，还是需要接入更多的B2B方案时，你都会感谢当初清晰的分离。

那么，如何具体划分业务层和表示层呢？有几个核心准则值得遵循：

首先，坚决将UI相关代码与核心业务逻辑分离开。这意味着，那些与UI紧密耦合的代码（比如调用了ASP内部对象的MTS对象），应该和纯粹的业务逻辑代码划清界限，最好能放到不同的DLL中去。

其次，事务管理最好远离ASP页面。虽说在某些简单场景下，直接在ASP里处理事务很方便，但一旦引入组件和多层架构，情况就变了。组件不该依赖客户端层（比如ASP）来管理自己的事务和业务语义。

最后，一个关于性能的关键建议：将使用请求（Request）和响应（Response）这类ASP内部对象的表示层组件，务必放在与Web服务器相同的机器、甚至同一个进程内。如果把它们丢到远程服务器上，所有对内部对象的调用都会变成低效的回调，由COM+服务器反过来调用IIS客户端，这会显著拖慢性能，并让安全配置复杂化。对于这类组件，正确的归宿是标记为“库激活”的COM+应用程序。

既然ASP身处于服务器端，那它就必须遵守服务器应用的共享资源规则，时刻把可伸缩性放在心上。具体来说：

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

尽量保持ASP页面的无状态性，从而为资源池化创造可能。

操作方式

当你纠结一段代码到底属于业务逻辑还是表示层时，这里有个简单的自测方法：“假如今后我的前端从ASP页面换成了按键式电话应用程序，这段代码还能复用吗？”如果答案是肯定的，那它很可能就该划归为业务逻辑或UI辅助代码。

反之，如果换了客户端，这段代码就完全没用武之地，或者它纯粹是构建用户界面的“脚手架”，那它无疑属于表示服务层。它应该待在ASP页面里，或者放在那些调用了ASP内部对象的组件中，而不是钻进业务对象组件里。

理解桌面与 ASP 客户机的区别

ASP作为一种特殊的组件客户端，与传统桌面上的单线程Win32应用有着本质区别。主要差异可以概括为以下几点：

线程管理：ASP本身是多线程客户端。这意味着大量并发活动可以同时进行，不同的用户可能在同一瞬间请求不同的ASP页面。因此，你的对象绝不能想当然地认为自己是系统的“唯一使用者”。一个常见的坏习惯，就是把对象存储在ASP的Session或Application变量里，这往往会引发意想不到的连锁反应。

安全环境：ASP由IIS 5.0执行，并且存在低、中、高三种隔离级别。不同的Web站点可以配置各异的安全设置，比如允许或拒绝匿名访问、选择身份验证方式等。这些组合产生了复杂多样的场景，最终你的对象可能会在不同用户账户的上下文中运行。

用户规模的弹性增长：这倒不是技术问题，而是Web应用程序天然特性带来的“甜蜜烦恼”。传统的桌面应用，要扩大用户基数，需要精心的部署计划。但ASP改变了游戏规则。一个部署好的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单元中。这意味着，如果一个对象在线程A中创建，那么对该对象的所有调用都必须由线程A来服务。如果多个线程（来自并发的网站用户）试图访问同一个STA对象实例，会引起线程排队等待，很容易成为整个应用的性能瓶颈。

更进一步，如果在Session范围内存储用Server.CreateObject创建的STA对象，实际上就把执行线程和当前用户锁死了。这将直接把应用程序的最大并发用户数限制在“20 x N”（N为处理器数量）这个默认的天花板上。

操作方式

如果你采纳了无状态对象的建议，那么就不需要为了复用而存储对象引用，更不该把它们放到Application范围里。各个客户端完全可以独立地创建、使用和销毁自己的对象实例。正因为对象不保存会话相关的状态，也就没必要在Session里持有它们了。

因此，推荐的做法是保持对象无状态。当需要数据时，让它直接访问数据库或其他存储介质（如Cookies、LDAP）。

如果确实需要使用Session或Application范围的数据，请记住，存进去的应该是数据本身，而不是封装了数据处理逻辑的对象。你可以专门创建一个类，来封装对这些值的访问和操作。

学习 IIS 5.0 中的新内容

Internet Information Server 5.0带来了不少新功能。关于这些改进的详细内容，J.D. Meier在MSDN的文章《沿用 IIS 5.0 中的 ASP》中已有全面阐述，值得深入研读。

以上就是关于ASP开发的一些关键准则。深入理解并实践这些原则，对于构建健壮、可扩展的ASP应用无疑大有裨益。