在ASP经典项目的代码库上加快生活难度的一件事是包含文件情况有点混乱。我有时会发现我正在寻找的函数被包含在一个完全不相关的包含文件中。有没有人对如何重构这一点有任何建议,以便人们可以更容易地告诉函数在哪里需要找到它?

编辑:有一件事我忘了问:vbscript有什么机制可以防止文件被包含两次?像#ifndef那样来自C?

有帮助吗?

解决方案

在接管经典ASP应用程序时,您可以做一些基本的事情,但您可能最终会后悔这样做。

  1. 删除重复的包含文件。我见过的每个经典ASP应用程序都有5个“login.asp”。 pages和7" datepicker.js"文件等等。寻找并删除所有重复项,然后根据需要更改应用程序其余部分中的引用。在删除文件时要小心对每个文件进行差异检查 - 通常复制的文件会略有不同,因为原作者复制了它,然后只更改了副本。对于Evolution来说这是一件好事,但对于代码来说并不是那么多。
  2. 创建合理的文件夹结构并将所有文件移入其中。这一点很明显,但这是你最后悔的事情。无论应用程序中的链接是相对的还是绝对的,您都必须更改它们中的大多数。
  3. 将所有包含文件合并为一个大文件。然后,您可以在逻辑上重新排序所有函数,并将它们分解为单独的,合理命名的文件。然后,您必须逐页浏览应用程序并找出每个页面上的include语句需要(或者坚持使用一个文件,并将其包含在每个页面上 - 我不记得是否这在ASP中是个好主意。我无法理解这里涉及的痛苦程度,并且假设现有的包含文件没有大量使用同名的全局变量。
  4. 我不会这样做。换句话说Steve Yegge(我认为),“一个经典的ASP应用程序没有任何问题,无法通过完全重写来修复”。我对此非常认真 - 我认为程序员在这个世界上浪费的时间并不比维护ASP应用程序更大,而且随着ASP越来越过时问题变得越来越严重。

其他提示

@ MusiGenisis 项目符号列表是很好的建议,但我不同意与 -

“我不会做任何这个。用史蒂夫·耶格(Steve Yegge)的话来说,“对于经典的ASP应用程序来说,没有任何问题,无法通过完全重写来修复”。我对此非常认真 - 我不认为程序员在这个世界上浪费的时间比维护ASP应用程序更大,而且随着ASP越来越过时问题变得越来越严重。“

一切都很好,但如果它是一个相当大的遗留应用程序,由于缺乏开发人员的时间/资源,通常无法完成重写。

我们有一个相当大的经典ASP应用程序,多年来已经成长为手臂和腿,它不是很漂亮但它确实满足了业务需求。我们没有时间在接下来的六个月里完成重写,这会很好,但是不可能。我们的方法是 -

  1. 如果需要新功能,则在ASP.NET中实现。这种情况发生在95%的时间。 5%边缘情况通常是新的应用程序代码触及旧应用程序的大量要点,要求我们进行大量经典的ASP重新工作,这可能会使应用程序更加脆弱。

  2. 如果功能发生变化,我们会评估是否可以以最小的影响重构ASP.NET。如果这是不可能的,那么我们将实现经典ASP中的更改并整理现有代码,例如我们简化包括文件嵌套,用更多跨浏览器友好代码替换javascript,这样的事情。

  3. 在回答你关于#ifndef's的问题时,我不敢相信。

  1. 将一个文件用于全局标题并包含(让我们将其命名为t-head.asp)。此文件包含在所有asp文件中。
  2. 使用一个文件使网站可视化全局标题(徽标,菜单等)并将其包含在后面。我们称之为t-begin.asp
  3. 使用一个文件使网站可视化全局页脚(版权,谷歌分析等)并关闭在t-begin.asp中打开的所有div或表。让我们称这个文件为t-end.asp
  4. 使用一个文件夹放置业务逻辑文件,称为BUS。此文件夹中的文件不能包含。文件中的每个函数都必须以逻辑单元的名称开头(IE:products.asp中的所有函数必须以product _ *开头)
  5. 使用一个文件夹放置一些名为UI的重用UI代码。此文件夹中的文件不能包含。
  6. 示例:

    <%@  Language=VBScript %>
    <% Option Explicit %>
    <% Response.Buffer = true%>
    <html>
    <head>
    <!--#include file="../general/t-head.asp"-->
    <!--#include file="../bus/product.asp"-->
    <title>Products page</title>
    </head>
    <body>
    <!--#include file="../general/t-begin.asp"-->
    
       <% 'all your code  %>
    
    <!--#include file="../general/t-end.asp"--> 
    </body>
    </html>
    

哇。令我惊讶的是,有多少人对ASP有仇恨。在体面的手中,它是设计Web应用程序的完美语言。

但是,我会承认,在ASP中管理包含文件的方式可能有点大脑 - 因为(取决于你如何使用它们)它们必须加载和解析,即使你没有使用一半其中包含的功能。

我倾向于有一个包含文件( initialise.asp 或其他一些),它本身包含指向多个函数库的链接( lib_http.asp lib_mssql。 asp 或类似的)并且所有库函数都是自包含的,因此不必担心交叉变量。任何全局变量都在主文件中声明和设置。这意味着我可以随时随地使用某个功能,而不用担心它的定义位置,它只是在那里使用。并且诸如Visual Studio和Primalscript之类的IDE具有“跳转到定义”的能力。当你找到一个你不认识的函数的调用时。

然后,在调用此主包含文件后,脚本中将包含任何特定于脚本的包含。

我承认这是一个需要大量内存的方法,因为所有库中的所有函数都是为每个脚本调用编译的,因此该方法需要为您开发的每个站点进行精炼 - 决定通过主站调用什么包括什么更具特定于页面。能够只加载你需要的东西会很好 - 但这是DLL的方法,并不适用于大多数现实世界的开发,而且你还要权衡编译小脚本的处理器成本vs加载组件。

简洁的目录结构是必需的并且易于开发,但是在现有站点中浏览所有代码并更改任何链接或mappath调用可能是一件苦差事。另外,请注意,某些IIS管理员不允许通过VBScript遍历目录的'.. \'方法,因此所有文件引用都必须是绝对路径。

我认为您应该考虑将代码从ASP VBScript移动到Visual Basic COM DLL。你会因为包含太多内容而感到轻松。

除了收到错误消息之外,我不知道防止双重包含的方法。您是否看到整个页面中放置了包含内容,这使得难以发现?

除此之外,您是否在开发服务器上使用代码和数据库的副本?根据我的经验,首先要做的是尽快将自己与实际网站分开。虽然最初很麻烦,但它可以让您自由地进行更改,而不会弄乱现场。在include和BAM中做一个微小的变化很容易!整个网站都倒塌了。

我已经完成了一些你所描述的项目并使用了以下策略:

完全重写 - 在有时间/金钱的情况下完美,但通常我会在出现问题时接听电话并尽快得到结果。

较小的项目 - 我打开IDE中的所有内容,然后开始搜索函数/ sub的所有项目文件,以便构建包含逻辑的知识。几乎每次都有,所有东西都散布在各地,所以我开始重建由业务逻辑组织的包含。我还会遇到内联代码(原始代码,而不是子代码或函数)抛出到include中,因此我通常只需将代码拉回页面进行重构。

更大的项目 - 我将使用一些代码来解析带有子/函数头的行的包含,并将这些代码转储到文本文件中以构建一个列表,列出哪些例程在哪里并引用它。当你在每个页面上获得大量内容并且无法理解代码库时,这会派上用场。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top