从ASP Classic迁移到.NET并减轻疼痛

Question

我们正在重新设计.NET 3.5中面向客户的网站部分。到目前为止一直很顺利，我们使用相同的工作流程和存储过程，在大多数情况下，最大的变化是UI，ORM（从词典到LINQ），显然是语言。到目前为止，大多数页面都是微不足道的，但现在我们正在处理最重的工作流程页面。

我们的报价接受部分的主页是1500行，其中约90％是ASP，可能还有1000行包括在函数调用中。我认为1500行也有点欺骗，因为我们正在处理像这样的宝石

function GetDealText(sUSCurASCII, sUSCurName, sTemplateOptionID, sSellerCompany, sOfferAmount, sSellerPremPercent, sTotalOfferToSeller, sSellerPremium, sMode, sSellerCurASCII, sSellerCurName, sTotalOfferToSeller_SellerCurr, sOfferAmount_SellerCurr, sSellerPremium_SellerCurr, sConditions, sListID,  sDescription, sSKU, sInv_tag, sFasc_loc, sSerialNoandModel, sQTY, iLoopCount, iBidCount, sHTMLConditions, sBidStatus, sBidID, byRef bAlreadyAccepted, sFasc_Address1, sFasc_City, sFasc_State_id, sFasc_Country_id, sFasc_Company_name, sListingCustID, sAskPrice_SellerCurr, sMinPrice_SellerCurr, sListingCur, sOrigLocation)

到目前为止，我一直使用的标准做法是花大约一个小时左右阅读应用程序，以熟悉它，但也删除已注释掉/弃用的代码。然后以深度优先的方式工作。我将从顶部开始并在aspx.cs文件中复制一段代码并开始重写，进行明显的重构，特别是为了利用我们的ORM。如果我得到一个我们没有的函数调用，我会写出定义。

在我编写了所有代码之后，我将在重构/测试中做几次通过。我只是想知道是否有人有任何关于如何使这个过程更容易/更有效的提示。

Answer 1

相信我，我确切地知道你来自哪里..我正在将一个大型应用程序从ASP经典迁移到.NET ..我还在学习ASP.NET！ ：S（是的，我很害怕！）。

我记忆中的主要内容是：

• 我不会偏离目前的设计太远（即没有大规模的“让我们把所有这些都搞砸，让它成为ASP.NET神奇的！”）由于ASP经典所具有的令人难以置信的高耦合量，这将是非常危险的。当然，如果你有信心，请填写你的靴子:)以后总是可以重构。
• 通过测试，测试和更多测试来支持所有内容！我真的很努力进入TDD，但它很难测试现有的应用程序，因此每次我删除一大块经典并替换为.NET时，我确保尽可能多的绿灯测试支持我。
• 研究很多，经典和.NET之间有一些主要的变化，有时候可以通过几行代码实现多行代码和经典包含，在编码之前思考..我已经学到了很难的方法，好几次：D

它非常像用你的代码玩Jenga :)

祝这个项目好运，再问任何问题，请问:)

Answer 2

在我编写了所有代码之后，我将在重构/测试中做几次通过。我只是想知道是否有人有任何关于如何使这个过程更容易/更有效的提示。

通常我不是TDD的粉丝，但在重构的情况下，它真的是要走的路。

首先写一些测试，验证你正在看的实际上在做什么。然后重构。这比仅仅“它看起来仍然有效”更可靠。

另一个巨大的好处是，当你重构页面下方或共享库中的某些内容时，你可以重新运行测试，而不是找出看似无关的难题。改变实际上是相关的

Answer 3

你是不是只需要重写就能从经典的ASP转到ASP 3.5？的skillz。我不得不处理一些遗留的ASP @work，我认为解析它并重新编写它更容易。

Answer 4

一个1500行的ASP页面？有很多要求包含文件的电话？不要告诉我 - 函数没有任何命名约定，告诉你哪个包含文件有它们的实现......这会带回记忆（颤抖）......

这听起来像你有一个非常坚实的方法 - 我不确定是否有任何神奇的方法来减轻你的痛苦。在您的转换工作之后，您的应用程序的体系结构仍然会变得混乱且UI重（即代码隐藏运行的工作流程），维护可能仍然相当痛苦，但您正在进行的重构应该肯定有帮助。

我希望你已经权衡了你正在做的升级而不是从头开始重写 - 只要你不打算过多地扩展应用程序并且你不是主要负责维护应用程序，升级像你这样复杂的基于工作流程的应用程序正在做的事情可能比从头开始重写更便宜，更好。与传统ASP相比，ASP.NET应该为您提供更好的机会来提高性能和可伸缩性。从你的问题来看，无论如何，我认为在讨论过程中为时已晚。

祝好运！

Answer 5

听起来你对事情有很好的把握。我见过很多人试图做直线音译，包括和所有，但它只是不起作用。你需要很好地理解ASP.Net是如何工作的，因为它与经典ASP有很大的不同，听起来好像你也有。

对于较大的文件，我会先尝试获得更高级别的视图。例如，我注意到的一件事是Classic ASP对函数调用很可怕。您将阅读一些代码并找到对函数的调用，而不知道它可能在何处实现。因此，经典ASP代码往往具有较长的函数和脚本，以避免那些令人讨厌的跳跃。我记得看到一个打印到40页的功能！直接解析这么多代码并不好玩。

ASP.Net使得更容易跟踪函数调用，因此您可以首先将较大的代码块分解为几个较小的函数。

Answer 6

不要告诉我 - 函数没有任何命名约定，告诉你哪个包含文件有它们的实现......这会带回记忆（颤抖）......

你是怎么猜的？ ;）

我希望你已经权衡了你正在做的升级而不是从头开始重写 - 只要你不打算过多地扩展应用程序并且你不是主要负责维护应用程序，升级像你这样复杂的基于工作流程的应用程序正在做的事情可能比从头开始重写更便宜，更好。与传统ASP相比，ASP.NET应该为您提供更好的机会来提高性能和可伸缩性。从你的问题来看，无论如何，我认为在讨论过程中为时已晚。

这是我们谈到的。基于时机（试图击败竞争对手的网站发布）和资源（基本上是两个开发人员），有意义的是不从轨道上攻击网站。事情实际上比我预期的要好得多。我们甚至从计划阶段就知道这段代码会给我们带来最多的问题。你应该看到所涉及的经典ASP页面的修订历史，这是一场大屠杀。

对于较大的文件，我会先尝试获得更高级别的视图。例如，我注意到的一件事是Classic ASP对函数调用很可怕。您将阅读一些代码并找到对函数的调用，而不知道它可能在何处实现。因此，经典ASP代码往往具有较长的函数和脚本，以避免那些令人讨厌的跳跃。我记得看到一个打印到40页的功能！直接解析这么多代码并不好玩。

我实际上对使用遗留代码有很多不满，所以我对系统有了很好的高层次理解。你对函数长度是正确的，有一些例程（大多数我已经重构为更小的例程），这是新站点上任何aspx页面/辅助类/ ORM的3-4倍。

Answer 7

我曾经遇到一个从ASP移植的.Net应用程序。 .aspx页面完全是空白的。为了呈现UI，开发人员在后面的代码中使用了StringBuilders，然后执行了response.write。这是错误的做法！

Answer 8

我曾经遇到一个从ASP移植的.Net应用程序。 .aspx页面完全是空白的。为了呈现UI，开发人员在后面的代码中使用了StringBuilders，然后执行了response.write。这是错误的做法！

我已经看到它以其他方式完成，页面后面的代码是空白的，除了声明全局变量，然后VBScript留在ASPX中。