第15章(COM+用程序459 下载 15.1.1拦截原理 COM+能够在应用程序和COM对象(组件)之间插入代码。在本章你将看到,这种拦截 ( Interception)是如何通过COM实现的,但现在把这个过程想象为一种COM+“粘性”代码, 只要COM对象的方法或属性在应用程序中使用,就调用这段代码,完成一些初始的设置过程, 然后调用真正的对象方法 为了理解拦截所能提供的益处和功能,先考虑一个典型的Web应用程序:有多个用户每 天以较高的频率访问同一个ASP页面,基于组件的Web应用程序中每个ASP页将包含完成下面 个基本步骤的ASP脚本 创建一个或多个COM对象 使用COM对象生成页面。 取消这些COM对象 假如一天之内收到50000个关于该页面的请求,如果该页面创建两个COM对象,那就需 要创建和取消1000个COM对象。考虑到创建和取消COM对象需要的计算机资源的总开销, 相比之下循环使用COM对象效率更高。当ASP完成调用COM对象以后,将其放入一个缓冲池 内,并可从缓冲池中取出,由其他的ASP页面重复使用。我们将看到这会明显提高Web站点的 性能。如果所使用的对象在每次创建使用之前(例如连接一个数据库或载入值),进行合理的初 始化工作,可使web站点的潜在性能进一步提高。使用缓冲,可以仅进行一次初始化工作 依据这种循环的思想,理想的ASP页面中的理想的ASP脚本应该依据下面的基本步骤: ·在建立COM对象前,查看缓冲池内是否存在该对象可供重复使用,如果没有,则创建 个新的对象 ·使用COM对象来生成一个页面。 将COM对象返回缓冲池,以供其他页面使用 这个循环过程听起来是很理想。当然实际上,这不可能在ASP脚本中实现。最简单的原 因是不能直接访问COM运行期( runtime),正如在第14章中讨论过的,活动脚本( Active Scripting)引擎调用运行期。即使能使用COM运行期,ASP脚本本身的限制和活动脚本引擎实 际上也阻止这种缓冲方式。暂且把这些限制放在一边,假如能够完成这种缓冲,可以想象 在实现时下面的这些复杂问题是不得不考虑的: 谁来管理对象的缓冲池? 缓冲池何时创建和取消 ·对象在缓冲池中何时创造和取消? 在什么阶段取消对象? 如何管理多个用户同时访问缓冲池? ASP脚本与缓冲池如何交互?程序员编写脚本时,能够记住在创建一个新对象之前必须 检查缓冲池,用完对象之后将一个COM对象返回到缓冲池吗? 显然在ASP脚本中实现这种功能是不可能的,即使能实现这种功能,在实现过程中,也 存在着两个非常重要的障碍需要解决 ·必须自己实现对象缓冲池的代码,要充分考虑到代码、测试、调试和维护周期 使用缓冲池的ASP页面代码必须要正确使用对象缓冲池,而让程序员考虑得太多是一种 错误的倾向。程序员可能经常忘记使用缓冲池。15.1.1 拦截原理 C O M +能够在应用程序和 C O M对象(组件)之间插入代码。在本章你将看到，这种拦截 ( i n t e r c e p t i o n )是如何通过C O M +实现的，但现在把这个过程想象为一种 C O M +“粘性”代码， 只要C O M对象的方法或属性在应用程序中使用，就调用这段代码，完成一些初始的设置过程， 然后调用真正的对象方法。 为了理解拦截所能提供的益处和功能，先考虑一个典型的 We b应用程序：有多个用户每 天以较高的频率访问同一个 A S P页面，基于组件的We b应用程序中每个A S P页将包含完成下面 三个基本步骤的A S P脚本。 • 创建一个或多个C O M对象。 • 使用C O M对象生成页面。 • 取消这些C O M对象。 假如一天之内收到 5 0 0 0 0个关于该页面的请求，如果该页面创建两个 C O M对象，那就需 要创建和取消1 0 0 0 0 0个C O M对象。考虑到创建和取消 C O M对象需要的计算机资源的总开销， 相比之下循环使用 C O M对象效率更高。当A S P完成调用C O M对象以后，将其放入一个缓冲池 内，并可从缓冲池中取出，由其他的 A S P页面重复使用。我们将看到这会明显提高 We b站点的 性能。如果所使用的对象在每次创建使用之前 (例如连接一个数据库或载入值 )，进行合理的初 始化工作，可使 We b站点的潜在性能进一步提高。使用缓冲，可以仅进行一次初始化工作。 依据这种循环的思想，理想的 A S P页面中的理想的A S P脚本应该依据下面的基本步骤： • 在建立C O M对象前，查看缓冲池内是否存在该对象可供重复使用，如果没有，则创建 一个新的对象。 • 使用C O M对象来生成一个页面。 • 将C O M对象返回缓冲池，以供其他页面使用。 这个循环过程听起来是很理想。当然实际上，这不可能在 A S P脚本中实现。最简单的原 因是不能直接访问 C O M运行期 ( r u n t i m e )，正如在第 1 4章中讨论过的，活动脚本 ( A c t i v e S c r i p t i n g )引擎调用运行期。即使能使用 C O M运行期，A S P脚本本身的限制和活动脚本引擎实 际上也阻止这种缓冲方式。暂且把这些限制放在一边，假如能够完成这种缓冲，可以想象， 在实现时下面的这些复杂问题是不得不考虑的： • 谁来管理对象的缓冲池？ • 缓冲池何时创建和取消？ • 对象在缓冲池中何时创造和取消？ • 在什么阶段取消对象？ • 如何管理多个用户同时访问缓冲池？ • A S P脚本与缓冲池如何交互？程序员编写脚本时，能够记住在创建一个新对象之前必须 检查缓冲池，用完对象之后将一个 C O M对象返回到缓冲池吗？ 显然在A S P脚本中实现这种功能是不可能的，即使能实现这种功能，在实现过程中，也 存在着两个非常重要的障碍需要解决： • 必须自己实现对象缓冲池的代码，要充分考虑到代码、测试、调试和维护周期。 • 使用缓冲池的A S P页面代码必须要正确使用对象缓冲池，而让程序员考虑得太多是一种 错误的倾向。程序员可能经常忘记使用缓冲池。 第1 5章 C O M +应用程序计计459 下载