重构“包含文件地狱”

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

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

来源

2008-09-27 Jason Baker

在接管传统的ASP应用程序时，您可以做几件基本的事情，但最终可能会后悔做这些事情。

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

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

来源

2008-09-27 15:19:59 MusiGenesis

我希望这是我的一个选择。 :( 不幸的是，我没有太多的选择 – 2008-09-27 15:23:43

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

来源

2008-09-27 15:08:53 cruizer

为什么反对票？ COM组件将减少包含并为.NET迁移提供路径？ – jwmiller5 2008-12-17 16:59:49

COM组件真的很难管理，更新，版本控制等。 – 2011-02-01 20:03:25

@MusiGenisis子弹点列表是从善如流，但我不同意 -

。“我不会做任何的这个套用史蒂夫·耶格（我认为），”有没有错一个经典的ASP应用程序，无法通过全部重写来修复“。我对此非常认真 - 我认为在这个世界上，程序员的时间不会比维护ASP应用程序更浪费时间，问题只是随着ASP越来越过时，情况变得更糟。“

一切都很好，但如果它是一个可观的遗留应用程序做完整的重新写入通常是不可能的，由于缺乏开发人员的时间/资源。

我们有一个相当大的经典ASP应用程序，这些应用程序多年来一直在增长手臂和腿部，这并不美观，但确实满足了业务需求。我们没有时间花费接下来的六个月来完成重写，这很好，但不可能。我们的方法是 -

在需要新功能的地方，它在ASP.NET中实现。这发生在95％的时间。 5％的边缘情况通常是因为新应用程序代码触及旧应用程序需要我们执行大量经典ASP重新工作，导致应用程序更加脆弱。
在功能发生变化的地方，我们会评估我们是否能够以最小的影响重构ASP.NET。如果这不可行，那么我们将在经典的ASP中实现这一改变，并整理现有的代码。简化包含文件嵌套，用更多的跨浏览器友好代码替换JavaScript，这种事情。

在回答关于＃ifndef's的问题时，恐怕没有等价物。

来源

2008-09-27 16:01:20 Kev

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

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

我往往有一个包含文件（initialise.asp或类似），其本身包含指向几个函数库（lib_http.asp，lib_mssql.asp或类似）和所有的库函数是自包含的，所以没有对交叉变量担心。任何全局变量都在主文件中声明和设置。这意味着我可以随时随地使用某个功能，而不用担心它定义在哪里，只是在那里使用而已。而像Visual Studio和Primalscript这样的IDE可以在你找到一个你不认识的函数的调用时“跳到定义”。

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

我承认，这是一种渴望内存的方法，因为所有库中的所有函数都是为每个脚本调用编译的，所以该方法需要针对您开发的每个站点进行细化 - 决定通过主函数调用哪些include和什么是更具体的页面。能够只加载你所需要的是很好的 - 但这是DLL方法，并且不适用于大多数现实世界的开发，并且你还必须权衡编译小脚本的处理器成本和加载组件。

一个简洁的目录结构是必需的，很容易开发，但它可能是一件琐碎的事情，可能会涉及现有站点中的所有代码并更改任何链接或mappath调用。此外，请注意某些IIS管理员不允许通过VBScript遍历目录的方法，因此所有文件引用都必须是绝对路径。

来源

2008-09-29 09:44:35

使用一个文件到全局标题和包含（让它命名为t-head.asp）。该文件包含在所有的asp文件中。
使用一个文件制作网站可视化全局标题（徽标，菜单等）并将其包含在后面。让我们称之为t开始。asp
使用一个文件来制作站点的可视全局页脚（版权，谷歌分析等），并关闭在t-begin.asp中打开的所有div或表格。让我们打电话给这个文件t-end.asp
使用一个文件夹放置业务逻辑文件，称为BUS。该文件夹中的文件不能包含。文件中的每个函数都必须以逻辑单元的名称开头（IE：products.asp中的所有函数必须以product_ *开头）
使用一个文件夹放置一些称为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-29 11:49:41

我不知道的方式，以避免双重包容，比得到一个错误信息等。你是否看到包含在整个页面中，这使得它们难以辨认？

就像旁边一样，你是在开发服务器上使用代码和数据库的副本吗？根据我的经验，首先要做的就是把你自己从现场直接分开。虽然最初的麻烦，它会给你自由做出修改而不会搞乱现场。在包含和BAM中做一个小小的改变很容易！整个网站都崩溃了。

我已经通过了几个项目，如你所描述的工作，并使用了以下策略：

完全重写 - 完美的，当有时间/钱，但通常我得到的电话时出了问题和结果是尽快需要的。

更小的项目 - 我打开IDE中的所有内容，并开始搜索函数/子文件的所有项目文件，以建立包含逻辑的知识。每次都差不多，每件事都随处可见，所以我开始重新构建由业务逻辑组织的包含。我还运行了内嵌代码（原始代码，不是subs或函数），所以我通常会把代码放回到页面中以供稍后重构。

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

来源

2008-10-01 03:02:13 user14094

重构“包含文件地狱”

回答

相关问题