|
|
|
7i24.Com不停为您服务
服务器端的 <!--#include--> 是非常有用的语句。它允许你开发模块化，可重用，易于维护的 ASP 代码。
当我们为 ASP 具有如此功能而高兴时，不要忘了庞大的包含文件会吞噬掉有限的内存空间，使服务器的性能下降，使某些动态操作受到影响(创建对象，编译脚本等等)。
在说 include 文件的坏话之前，我们先了解一下 ASP 和包含文件是如何工作的。当 page 1(包含文件inc.asp) 第一次被请求时，它和它的包含文件进行组合，编译后进入到内存中。当 page 2(包含文件inc.asp)被请求时，服务器会做相同的工作。也就是说，同样的包含文件又重新编译了一次，并占据了内存。我们可以设想一下，如果有1000个这样的页面被请求，将会有1000个重复的包含文件编译后存放在内存中，这无疑会消耗大量的内存，使服务器的整体性能下降。
出于一种习惯，我们常把公用代码放在一个文件中，然后在其他 ASP 文件中调用。比如在 page1.asp 中调用包含文件 inc.asp 的 function1，在 page2.asp 中调用 inc.asp 的 function2。或许 page1.asp 不需要 function2，pge2.asp 不需要 function1，在其他语言中这似乎没什么重要，但是在 ASP 中，它意味着浪费，不仅在时间上而且在空间上。
推荐的做法是将包含文件化整为零，这样既保持了包含文件的灵活性，可重用性等诸多优点又不会因包含文件过于庞大而消耗大量的内存。或许你的包含文件中有复杂的逻辑处理，不能用化整为零的方法减小它的大小，那么建议将代码放到组件里，让组件来完成这个功能是更有效的方法。
如果你没有使用过 C++ 或者 VB 这样的语言也没有关系，用脚本语言一样可以创建组件，这就是我们常提到的"Windows Script Component"。在包含文件这方面，WSC 通常要优于 ASP，这与它的机制有关。当用户请求一个页面(含有WSC)时，服务器将创建 WSC 组件的一个实例，脚本引擎从磁盘装入源码，进行编译并放在内存中，与 ASP 不同的地方就是在随后的请求中，所有页面将共享这个已被编译的对象。这就是 WSC 比 ASP 高效的地方。
如果你觉得没有必要为一个小小的包含文件大动干戈，那你可以寄希望于 ASP3，其中的 Server.Execute 和 Server.Transfer 会更快速，更有效的完成包含文件的功能。( 参见文章：ASP3 的新特性 )
使用频率最高的包含文件大概就算 adovbs.inc 了。我们可以用下列代码代替它。
<!-- METADATA NAME="Microsoft ActiveX Data Objects 2.5 Library"
TYPE="TypeLib" UUID="{00000205-0000-0010-8000-00AA006D2EA4}"-->
或者
<!-- METADATA TYPE="TypeLib" FILE="C:\Program Files\Common Files\system\ado\msado15.dll"-->
尽管包含文件有点先天不足，但它的本质是好的：共享代码，设计模块化等等。不用包含文件是不明智的；滥用它是愚蠢的；那怎么用呢？
|
|
|
