5

在 ASP 经典项目的代码库上加快速度确实让生活变得困难的一件事是包含文件的情况有点混乱。我有时会发现我正在寻找的函数包含在一个完全不相关的包含文件中。有没有人对如何重构这个有任何建议，这样如果他们需要找到一个函数，就可以更容易地知道它在哪里？

编辑：我忘了问一件事：vbscript 是否有任何机制来防止文件被包含两次？有点像 C 中的#ifndef？

4

6 回答 6

14

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

  1. 消除重复的包含文件。我见过的每个经典 ASP 应用程序都有 5 个“login.asp”页面和 7 个“datepicker.js”文件等等。查找并删除所有重复项，然后根据需要更改应用程序其余部分中的引用。删除每个文件时要小心地对每个文件进行差异检查 - 通常重复的文件会有细微的差异，因为原作者复制了它，然后只更改了副本。这对 Evolution 来说是一件好事，但对代码来说却不是。
  2. 创建一个合理的文件夹结构并将所有文件移入其中。这个很明显，但这是你最后悔做的一个。无论应用程序中的链接是相对的还是绝对的，您都必须更改其中的大部分。
  3. 将所有包含文件合并到一个大文件中。然后，您可以对所有函数进行逻辑重新排序，并将它们分解为单独的、合理命名的文件。然后，您必须逐页浏览应用程序并确定每个页面上的包含语句需要是什么（或坚持使用一个文件，然后将其包含在每个页面上 - 我不记得是否这在 ASP 中是个好主意）。我无法理解这里所涉及的痛苦程度，这是假设现有的包含文件没有大量使用同名全局变量。

我不会做这些。套用 Steve Yegge（我认为）的话，“经典的 ASP 应用程序没有任何问题，但无法通过完全重写来修复”。我对此非常认真 - 我认为在这个世界上没有比维护 ASP 应用程序更浪费程序员的时间了，而且随着 ASP 越来越过时，问题只会变得更糟。

于 2008-09-27T15:19:59.340 回答
10

@MusiGenisis要点列表是很好的建议，但我不同意 -

“我不会这样做。套用 Steve Yegge（我认为），“经典的 ASP 应用程序没有任何问题，无法通过完全重写来修复”。我对此非常认真 - 我不'认为在这个世界上没有比维护 ASP 应用程序更浪费程序员的时间了，而且随着 ASP 越来越过时，问题只会变得更糟。”

一切都很好，但如果它是一个相当大的遗留应用程序，由于缺乏开发人员时间/资源，通常不可能进行完全重写。

我们有一个相当大的经典 ASP 应用程序，多年来它已经发展壮大起来，它并不漂亮，但它确实满足了业务需求。我们没有时间花接下来的六个月完全重写，这很好，但不可能。我们的做法是——

  1. 在需要新功能的地方，它在 ASP.NET 中实现。这发生在 95% 的时间里。5% 的边缘情况通常是新应用程序代码与旧应用程序接触的大量点，需要我们进行大量经典的 ASP 返工，这可能会使应用程序更加脆弱。

  2. 如果功能发生变化，我们会评估是否可以重构为 ASP.NET 而影响最小。如果这不可行，那么我们将在经典 ASP 中实现更改，并在进行过程中整理现有代码，例如简化包含文件嵌套，用更跨浏览器友好的代码替换 javascript，诸如此类。

在回答您关于#ifndef 的问题时，恐怕没有等价物。

于 2008-09-27T16:01:20.660 回答
3
  1. 将一个文件用于全局标题并包含（让我们将其命名为 t-head.asp）。此文件包含在所有 asp 文件中。
  2. 使用一个文件来制作站点的可视全局标题（徽标、菜单等）并将其包含在 . 让我们称之为 t-begin.asp
  3. 使用一个文件使站点可视化全局页脚（版权、谷歌分析等）并关闭在 t-begin.asp 中打开的所有 div 或表。让我们将此文件称为 t-end.asp
  4. 使用一个文件夹来放置业务逻辑文件，称为 BUS。此文件夹中的文件不能包含包含。文件中的每个函数都必须以逻辑单元的名称开头（即：products.asp中的所有函数必须以product_*开头）
  5. 使用一个文件夹来放置一些称为 UI 的重复使用的 UI 代码。此文件夹中的文件不能包含包含。

例子：

<%@  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>
于 2008-09-29T11:49:41.277 回答
2

哇。有多少人讨厌 ASP，这经常让我感到惊讶。在体面的人手中，它是设计 Web 应用程序的完美语言。

但是，我承认在 ASP 中管理包含文件的方式可能有点让人头疼——因为（取决于您如何使用它们）即使您没有使用包含的一半函数，也必须加载和解析它们之内。

我倾向于有一个包含文件（initialise.asp或类似文件），它本身包含指向多个函数库（或类似）的链接lib_http.asp，lib_mssql.asp并且所有库函数都是自包含的，因此不必担心交叉变量。任何全局变量都在主文件中声明和设置。这意味着我可以在任何地方、任何时间使用一个函数，而不必担心它是在哪里定义的，它只是为了使用而存在。当您发现对您不认识的函数的调用时，诸如 Visual Studio 和 Primalscript 之类的 IDE 能够“跳转到定义”。

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

我承认这是一种需要大量内存的方法，因为所有库中的所有函数都是针对每个脚本调用进行编译的，因此该方法需要针对您开发的每个站点进行改进——决定通过主包含调用什么以及更多页面-具体的。能够只加载您需要的内容会很好——但这是 DLL 方法，不适用于大多数实际开发，而且您必须权衡编译小脚本与编译小脚本的处理器成本加载组件。

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

于 2008-09-29T09:44:35.463 回答
0

我认为您应该考虑将您的代码从 ASP VBScript 移动到 Visual Basic COM DLL。这会让你有太多的包含。

于 2008-09-27T15:08:53.220 回答
0

除了收到错误消息外，我不知道有什么方法可以防止双重包含。您是否看到整个页面都放置了包含，这使得它们难以被发现？

顺便说一句，您是否在开发服务器上使用代码和数据库的副本？根据我的经验，要做的第一件事是尽快将自己与实时站点分开。虽然最初很麻烦，但它可以让您自由地进行更改而不会弄乱实时站点。在包含和 BAM 中进行微小的更改很容易！整个网站宕机。

我已经完成了一些您描述的项目，并使用了以下策略：

完全重写 - 有时间/金钱时完美，但通常当出现问题并且需要尽快得到结果时我会接到电话。

Smaller projects - I open up everything in the IDE and just start searching all the project files for the functions/sub, in order to build a knowledge of the include logic. Pretty much each time, everything is spread out everywhere, so I start rebuilding the includes organized by business logic. I've also run across inline code (raw code, not subs or functions) thrown into an include, so I'll usually just pull the code back into the page for refactoring later.

Larger projects - I'll use some code I have laying around to parse the includes for lines with sub/function headers and dump those to a text file to build up a list of what routines are where and refer to that. This comes in handy when you've got a ton of includes on each page and can't get your head around the codebase.

于 2008-10-01T03:02:13.683 回答