ASP 规则指南

Posted 2023-05-11

参考技术A

　　 简介

　　 Active Server Page (ASP) 应用程序的成功常常取决于对体系结构和设计这两方面的取舍 考虑到 ASP 技术的范围之广和当前应用程序固有的复杂性 这种取舍是非常困难的 本文中 我将为您提供一些特定的指导方针 以助您成功开发基于 ASP 的应用程序

　　我已将指导方针整理成一组开发原则 在评估解决方案和技术时 可以应用以下原则帮助您做出决策 以下原则是我长期以来从成功的开发模式所得的经验积累

　　 原则 采用标准方法

　　建立命名约定并使目录结构标准化 可以帮助您大大提高 ASP 应用程序的可读性和可维护性 虽然目前尚无 ASP 应用程序的正式标准 许多开发人员还是建立了一些通用方式 在此 我将与您共享一些更为通用的方式

　　因为 ASP 技术依靠脚本引擎进行工作 而且脚本具有类型不严密的天性 命名约定也很模糊 在类型非常严密的语言中 变量将按照它的实际类型进行声明 在使用 ASP 技术时 通常按照处理变量的方式（而不是其实际数据类型）在 ASP 代码中声明变量 例如 在使用 Visual Basic(R) Scripting Edition (VBScript) 时 尽管所有的 VBScript 变量都是 Variant 你还是会将成功标志声明为 bSuccess（b 代表布尔型） 而不是 vSuccess（v 代表 Variant）

　　下表是一些通行的命名约定

　　变量前缀

　　前缀 使用的变量 变量示例

　　b or bln Boolean bSuccess

　　c or cur Currency cAmount

　　d or dbl Double dblQuantity

　　dt or dat Date and Time dtDate

　　f or flt Float fRatio

　　l or lng Long lMilliseconds

　　i or int Integer iCounter

　　s or str String sName

　　a or arr Array aUsers()

　　o or obj Object oPipeline

　　数据库对象的变量前缀

　　前缀 使用的变量 变量示例

　　cnn Connection cnnPubs

　　rst Recordset rstAuthors

　　cmd Command cmdEmployee

　　fld Field fldLastName

　　范围及前缀的用法

　　前缀 说明

　　g_ 创建于 Global asa

　　m_ 对于 ASP 页或在 Include 文件中是局部的

　　（没有前缀） 非静态变量 对于过程来说前缀是局部的

　　Knowledge Base (KB) 中的一篇文章 Q 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 （英文）

　　 原则 设计为在服务下运行

　　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 （英文）

　　 Q INFO: Security Issues with Objects in ASP and ISAPI Extensions （英文）

　　 原则 封装业务逻辑

　　ASP 技术通过生成 html 输出提供了表示服务 简而言之 它会生成用户界面 您需要将商务逻辑从 ASP 表示脚本中分隔开来 即使您不使用 组件将业务逻辑从 ASP 代码中分隔开来 至少也要将业务逻辑分隔到函数和 include 文件中 以提高可维护性 可读性和可重用性 在需要排除故障和隔离问题时 您还能体会模块化设计方法的好处

　　调用脚本内部调用函数和方法 可避免代码乱作一团 并能在 ASP 应用程序中添加结构 下面举例说明从 ASP 代码中 将逻辑分离到方法调用中

　　lt;% Main()

　　MyBizMethod()

　　

　　Sub Main()

　　GetData()

　　DisplayData()

　　End Sub

　　%>

　　在使用包含 ASP 功能的技术时 可以应用这一原则 下面举一个使用 Visual Basic WebClass 时的例子 说明如何使用这一原则

　　因为 WebClass 本身引用 ASP 代码生成 HTML 所以您不要将业务逻辑直接置于 WebClass 内 因为这是您的表示层 不在 MTS/+ 下直接运行 WebClass

　　从 WebClass 可以调用能运行在 MTS/+ 中的单独业务组件

　　您可以决定创建自己的 具有对 ASP 引用的 组件 而不是依赖于 WebClass 框架结构和额外的 WebClass 运行时开销 — 您也可以使用 ASP 脚本直接将业务组件自动化

　　 原则 尽晚获取资源 尽早释放资源

　　常见的问题是 从桌面系统到服务器的过渡 许多具有桌面系统背景的开发人员从来没有为服务器的一些问题和资源共享担心过 在传统的桌面应用程序中 连接到服务器是个耗时的过程 为了改善用户的体验 通常采用尽早获取资源和推迟释放资源的方法 例如 许多应用程序会在它的整个运行时间内始终连接着数据库

　　这种方式在传统的桌面应用程序中能够正常工作 其原因是用户数量非常明确 容易加以控制 并且后端与前端紧密连接 然而 对于当前的 Web 应用程序 这种方式已经不可行了 其原因是有限的服务器资源将面对越来越多的用户 为了使您的应用程序能够应付用户的增加 您需要尽晚获取资源 尽早释放资源

　　共用有助于增加这一方式的有效性 通过共用 多个用户能够共享资源 而且等待时间最少 对服务器的影响也最小 例如 在处理数据库时 ODBC 连接共用和 OLEDB 资源共用可以实现从共用池中选择连接 最大程度地减少连接数据库的开销

　　有关共用 ADO 的详细信息 请参阅 Pooling in Microsoft Data Access Components （英文）

　　 原则 使用数据库维护复杂的状态

　　尽管 HTTP 协议是无状态的 ASP 开发人员还是会经常使用 ASP 功能内置的状态保持机制 例如 使用 ASP 技术内置的 Application 对象 开发人员所保存的资源能够为应用程序的所有用户共享 通过使用 ASP 内置的 Session 对象 开发人员只为单个用户保存资源

　　尽管听起来在 ASP 技术的 Session 对象中保存信息是一个非常方便的保持状态的方式 然而这一方式付出的代价太大 而且它也可能成为对可伸缩性的最大的限制因素之一 应用程序的可伸缩性本质上是随着用户数目的增长能够继续保持其性能的能力 而对于每一用户 在会话超时或被放弃之前 Session 对象都会消耗服务器的资源 会话还会将您捆绑到一台服务器上 从而限制您利用 Web 集群的功能 请尽可能不要使用 ASP Session 对象进行状态管理 如果您完全没有使用会话 您就可以禁用 Web 应用程序的 Session 状态（请参阅 IIS 文档） 否则 您可以使用下述语句 针对每一页禁用 Session 状态

　　<%@ENABLESESSIONSTATE=False %>

　　对于一些简单的数据 您可以使用 QueryString cookie 或隐藏的窗体域保持 ASP 请求间的状态 然后 对于更为复杂的信息 通常推荐您使用数据库 一般所采用的方式是生成某一特有的标识符 然后发送到每一个发出请求的客户机 并保存为隐藏的窗体域 在随后的请求中 这一特有的标识符被用于在数据库中查找与该用户相关的状态信息 这一方式提供了更高的可伸缩性和更为简洁明了的代码

　　有关使用 QueryString cookie 和隐藏的窗体域的详细信息 请参阅 Q HOWTO: Persisting Values Without Sessions （英文）

　　 原则 使用 Server CreateObject 创建对象

　　在创建 ASP 技术的对象时 您可以选择 <OBJECT> 标记 Server CreateObject 和 CreateObject 三种方式 每项技术的行为略有不同 尽管在 IIS 中 使用 <OBJECT> 标记或 CreateObject 比 Server CreateObject 略具性能优势 我们一般还是推荐使用 Server CreateObject 以便于 ASP 应用程序认知您的对象 （注意在 IIS 中 前两项与 Server CreateObject 相比 已经没有性能优势

　　<OBJECT> 标记仅在调用第一个方法时才会创建组件 因此能够节省资源 Server CreateObject 使用 ASP 技术内置的 Server 对象创建组件 实质上 它只是执行了 CoCreateInstance 但是 ASP 却能够认知这一对象 同时 还将调用 ASP 技术的传统的 OnStartPage 和 OnEndPage （注意最好在 IIS 或者更高版本中使用 ObjectContext） 如果您只是使用 CreateObject 您将越过 ASP 技术而直接使用 Scripting 引擎

　　以下是一个可能出现的例外情况 当您通过防火墙进行调用时 您可能需要调用 CreateObject 而不是 Server CreateObject 详细信息 请参阅 Q PRB: Server CreateObject Fails when Object is Behind Firewall （英文）

　　 原则 提供丰富的疑难解答信息

　　确保在您所有的 ASP 应用程序中都包含了错误处理过程 而且 确保您提供了有用的诊断信息 我还没有碰到有哪个人抱怨错误信息太具有说明性了 请确保在错误日志中包含以下信息

　　用户上下文（如果您正在使用组件 您可以调用 GetUserName）

　　线程 ID（在组件中 可以调用 GetCurrentThreadId）<

　　时间

　　完整的错误信息（包括编号 来源和说明）

　　参数值

　　因为将在 ASP 下运行 您可能希望将这些信息写到文件或 NT 的事件日志 您还可以创建记录关键的应用程序事件的应用程序事件日志 以备诊断应用程序错误时使用

　　以下文章提供了有关错误处理技术的详细信息

　　 Bulletproofing Your ASP Components （英文） Charles Alexander 著

　　 Fitch & Mather Stocks: Web Application Design （英文）

　　 Handling and Avoiding Web Page Errors Part : The Basics （英文）

　　 Handling and Avoiding Web Page Errors Part : Run Time Errors （英文）

　　 Handling and Avoiding Web Page Errors Part : An Ounce of Prevention （英文）

　　 原则 测试性能 可伸缩性和可靠性

　　浏览器并不是准确的测试方式 它只能向您展示应用程序可能的用途 请针对您的应用程序设置特定的性能目标 并使用 Web Application Stress Tool 等负载工具进行压力测试 您需要自己决定您的环境所能接受的条件 以下是一些帮助您启动测试过程的通用指导方针

　　通过测试 ASP 每秒钟的请求数对性能进行测试 并建立一个最小的阈值 一般情况下 不执行数据库访问的简单 ASP 页每秒钟至少应返回 页 调用组件或访问数据库的页每秒钟至少返回 页

　　向应用程序不停地追加用户 直到每秒钟的请求数低于预先设置的阈值 用这种方式测试可伸缩性

　　从 Web 集群中移去机器 并检查错误和故障情况 以便测试可靠性

　　将测试环境与实际运行的环境相匹配 甚至防火墙也不例外 这听起来代价很高 但我曾经听说过开发人员因为没有考虑到防火墙 而丢失了工作

　　有关使用 Web Application Stress Tool 测试 ASP 应用程序的详细信息 请参阅 I Can t Stress It Enough Load Test Your ASP Application （英文）

　　 原则 增加隔离性

　　使用隔离功能保护您的应用程序过程能够极大地增强服务器的稳定性 谈到 Internet 应用程序 是否使用隔离功能的后果可能会有巨大的差别 一个是应用程序崩溃 一个是服务器当机 保护主 IIS 进程 (InetInfo exe) 通常会排在优先级列表的较高位置 在您使用组件时 这一点尤为突出

　　通常所采用的保护主 ISS 进程的技术是使 Web 应用程序运行在各自的内存空间中 在 Internet Services Manager 中 您可以针对每一个 Web 设置这一选项 虽然因对进程进行编组而开销的系统资源会对性能有些微的影响 但对应用程序所起的保护作用值得付出这一代价 在 IIS 下 您可以采用进程内 (in process) 和进程外（out of process OOP）两种方式运行应用程序 OOP 应用程序会运行在新的 Mtx exe 实例中 在 IIS 下 您还能使用其他的隔离选项 可以将隔离级别设置为 低 （对 Inetinfo exe 来说是进程内应用程序） 中 （DllHost exe 共享实例）或 高 （Dllhost exe的非共享实例）

　　除了将 Web 应用程序隔离在它们自己的内存空间中之外 您可能还希望隔离不信任的组件 不信任的组件通常是在实际环境中没有通过测试时间的考验的组件 您可以在 Server 包中运行这些组件 这样它们会运行在新的 Dllhost exe 实例中

　　一般而言 如果要在性能和保护措施之间采取中庸之道 方式如下 在 高 隔离状态运行 Web 应用程序 在库包中运行组件 这种方式最大限度地减少了编组开支 同时在进程之间提供了最强的保护作用

　　详细信息 请参阅文章 Server Reliability Through Process Isolation （英文）

　　 原则 不要滥用线程共用组

　　在 IIS 下 针对每个受 MTS 管理的处理器 ASP 的默认共用组是 个线程 在 IIS 中 默认值是 这就意味着每一线程都是一份潜在的宝贵资源 能够处理多个客户机请求 您同样需要避免调用会出现阻塞的方法 如进行大的数据库调用 如果您有要执行这种操作的工作 它将阻止 ASP 应用程序将响应快速返回到客户机 则请考虑使用队列功能 例如 在 NT 中 可以使用 MSMQ 在 Windows 中 可以使用 Q 在 Windows 中 可以使用 Queued Components（排队组件）

lishixinzhi/Article/program/net/201311/12933

微软ASP.NET站点部署指南

微软ASP.NET站点部署指南 

1.  综述

现在，程序也已经在本机IIS部署了，也测试了，该到发布到互联网上的时候了。本章节你将创建一个虚拟主机账户，然后将程序发布到该生产环境。

提醒：如果根据本章节所做的操作出现错误信息或一些功能不正常的话，请务必check Troubleshooting页面。

2.  选择主机提供商

对于Contoso University程序和本系列教程，你需要选择一个支持ASP.NET 4和Web Deploy的虚拟主机。我们选择了一个主机提供商一般来展示一个完整的部署体验过程。由于每个不同的提供商提供不同的功能和部署流程，不过本教程的部署流程基本上涵盖了所有的步骤。本教程使用的提供商是Cytanium.com，使用它不代表认可以及推荐它。

如果你准备选择提供商了，你可以根据微软站点的提供商列表来比较各自支持的功能和价格。

3.  创建账户

在提供商那里创建一个账户，如果以及支持完整版的的话，我们在这个章节也不需要用到。但是后面的章节会讲到如何数据迁移至完整版的SQL Server上。

本教程，不需要你注册新的域名，你可以直接用现有的域名，也可以用提供商提供的临时URL地址来访问。

账户创建以后，通常你会收到一封欢迎邮件，里面包含了所有需要部署和管理站点的信息。不同的提供商发的邮件内容是不一样的，但是大概都是类似的。Cytanium发送的邮件一般包括如下信息：

1. 控制面板的URL地址，通过这个地址可以管理站点的配置信息。账户和密码也包含在里面（以后修改过了，不用尝试登陆啦）。
   

   

2. 默认的.NET Framework版本以及如何修改版本信息。大部分虚拟主机站点提供的都是2.0版（支持2.0/3.0/3.5的程序），但Contoso University是基于.NET Framework 4的程序，所以需要稍后修改这个设置。
   

   

3. 网站临时URL地址，创建的时候输入了以及存在的域名（contosouniversity.com）。因此，临时地址是：http://contosouniversity.com.vserver01.cytaniu.com。
   

   

4. 如何建立数据库和设置连接字符串的一些信息：
   

   

5. 部署程序需要的工具和设置信息（也提到了WebMatrix方面的信息，此处忽略）。
   

   

4.  设置.Net Framework版本

Cytanium欢迎邮件里有一个可以更改.NET Framework版本的连接，该页面介绍了如何通过Cytanium控制面板来设置。其它的提供商的控制面板也许是不一样的，可能用其它的方式去操作。

访问控制面板地址，输入用户名和密码以后，将看到如下页面：

在Hosting Spaces框里，移动鼠标上去能看到2个连接，选择Web Sites。

在Web Sites框里，点击contosouniversity.com（创建账户时输入的名字）。

在Web Site Properties框里，选择Extensions选项卡：

将ASP.NET从2.0 Integrated Pipeline修改才4.0 (Integrated Pipeline)，然后点击更新Update。

5.  发布程序到虚拟主机

修改当前的build配置为Release，你可以从工具栏选择（如下图），或者从编译（Build）菜单里的配置管理器（Configuration Manager）里选择。

Solution Explorer里，右键ContosoUniversity项目，选择发布(Publish），弹出Publish Web对话框，里面显示的是Test profile，因为目前为止你只创建了这个。

在Publish profile框里，选择新建new：

输入新名称"Production"

在Service URL里输入提供商欢迎邮件里提供的地址

在Site/application里输入提供商欢迎邮件里提供的名称

选择 Mark as IIS application on destination.

确保选择上Leave extra files on destination (do not delete)，如果不选择这个Web Deploy将会删除目标站点上有而解决方案里没有的文件，第一次部署没有影响，但是以后的升级部署可就惨了，选上它只是避免这些问题。例如，它会删除生产环境Elmah文件夹的日志文件（你解决方案里没有）。

选择Allow untrusted certificate.

输入提供商提供的认证账户信息

选择Save password以便不用每次都输入密码

点击发布（Publish）

这样程序就发布到虚拟主机上了，Output 窗口会显示发布结果。

6.  设置Elmah目录权限

还记得上个章节Elmah记录日志的时候需要设置写权限才能写入XML文件呢，在你本机的IIS上部署的时候需要手工设置。本小节，你将使用Cytanium 来设置这个（其它提供商也行不允许这么做，通常情况他们会提供特殊的目录让你写文件，这样的话，你就要修改你的程序只能在特殊的目录里写文件了）。

你可以在Cytanium控制面板里设置权限，访问控制面板URL，然后选择File Manager。

File Manager框里选择contosouniversity.com，可以看到根目录wwwrooot。点击Elmah右边的关闭锁图片。

在弹出的File/Folder Permissions窗口里，为contosouniversity.com选择Read和Write，点击保存（Set Permissions）。

7.  设置Bin目录权限

对于Cytanium和SQL Server Compact，还有另外一个文件夹权限问题需要注意， 如果你运行程序的话，首页是没有问题的，但是其它牵涉到数据库操作的页面都会出现如下错误：

System.UnauthorizedAccessException : Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

原因是为了读取原生的程序集，NETWORK SERVICE账户会从bin目录读取这些程序集，但是它现在没有权限。（如果你想看到这个错误信息，你需要修改Web.config的错误配置为Off，然后重新部署，因为默认的生产环境显示的自定义错误页，而且你在错误报告页面也查不到错误信息，是因为根本就没权限写入这个错误信息。）

再次打开File Manager里的wwwroot，点击bin目录傍边的关闭锁图片，在File Folder Permissions弹窗里为contosouniversity.com和NETWORK SERVICE都选择上Read。然后选择Replace permissions on all child objects以后，点击Set Permissions保存设置。

8.  产品环境测试

打开创建账户时给的临时访问地址（该例是：http://contosouniversity.com.vserver01.cytanium.com），你可以看到和你本机Visual Studio里一样效果的首页，只不过不再显示Test和Dev指示符了，这就是说Web.config 的transformation以后的信息是正确的。

访问Students页面验证数据库里没有student记录：

访问Instructors页面验证Instructors数据依然保留在数据库里：

和测试环境一样，你需要验证生产环境的数据库是否能否正常操作，但通常不想输入测试数据进去，因为它是真正的生产环境。本章节依然使用同样的方式来测试，在真正的生产环境里你需要使用不同的方式去做这个事情，比如不输入测试数据也能验证的办法。当然除了要求不大，你也可以添加一些实用的数据进行测试然后再删除。

添加一个student然后访问Students页面看看数据是否存在，以此来验证数据库操作是否正常：

从Courses菜单选择Update Credits页面验证授权认证是否正常。正常显示了Log In 页面。

输入管理员账户和密码登录以后，Update Credits页面可以正常显示，说明ASP.NET membership数据库工作正常。

测试Elmah在生产错误日志的时候是否正常记录日志，访问一个非法的URL地址（例如Studentsxxx.aspx）。和以前一样，会显示GenericErrorPage.aspx页面，点击Log Out退出连接，运行Elmah.axd，再次显示Log In页面（验证了Web.config里对于Elmah认证的transform是否正确），登录以后，就可以看到刚才生产的错误信息了。

现在，已经成功部署了站点，并且验证了测试结果，这个站点就可以在公网上正式公开运行了。

9.  创建更可靠的测试环境

在第5章我们提到了最可靠的测试方式是在主机提供商那里购买第2个账户作为测试环境，花费自然也要比在你本机IIS测试要高，但是为了防止生产环境出问题，购买第2个账户做测试也只值得的。

部署测试账户的流程和部署生产环境是几乎一样的，只需要走如下工作：

1. 参考第3章和第4章，创建一个新的build配置和Web.config transformation文件
2. 和上面部署生产环境一样，在主机提供商那里再购买一个账户，以便部署这个新的build 配置。
3. 创建新的publish profile以便部署到这个测试账户上。

10.    防止测试站点被公开

测试账户要考虑的事情是，它运行在公网上，但你不想让其它人访问，保存这个站点私有的话，你可以这么做：

1. 联系主机提供商为你设置防火墙规则以便只有你的IP地址才能访问测试
2. 掩饰URL路径，以便不合生产环境的URL地址相似。
3. 使用robots.txt文件禁用搜索引擎爬行收录你的地址。

第1调是最常用的，但每个提供商所处理的流程这里就不写了，如果你的提供商可以设置只允许你的IP地址房屋内，理论上就不用担心搜索引擎爬行了，尽管这样，部署一个robots.txt 以防万一。

部署的robots.txt应该是如下这样的：

	User-agent: * Disallow: /

User-agent告诉搜索引擎下面的规则适用于所有的搜索引擎爬虫， Disallow 意味着所有的页面都不允许爬虫访问。

生产环境需要收录，所以不要部署这个文件。参考：Can I exclude specific files or folders from deployment? 以确保只在Release build里排除这个文件。