asp.net - 从 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。如果我得到一个我们没有的函数调用，我会写出定义。

在我完成所有编码后，我将在重构/测试中进行几次传递。我只是想知道是否有人对如何使这个过程更容易/更有效有任何提示。

score 6 · Accepted Answer

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

我一直牢记在心的主要事情是：

我并没有偏离当前的设计太远（即没有大规模的“让我们把所有这些都撕掉，让它成为 ASP.NET 神奇！）由于 ASP 经典往往具有难以置信的大量耦合，这将是非常危险的。当然，如果您有信心，请做好准备 :) 这总是可以在以后重构。
通过测试、测试和更多测试来备份所有内容！我真的很努力地进入 TDD，但是测试现有应用程序非常困难，所以每次我删除一大块经典并替换为 .NET 时，我都会确保我有尽可能多的绿灯测试支持我。
进行了很多研究，经典和 .NET 之间存在一些重大变化，有时可以通过几行代码来实现经典中包含的多行代码，在编码之前三思而后行。我已经很难学会这一点，几次：D

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

祝项目好运，还有任何问题，请提问:)

score 2 · Accepted Answer

在我完成所有编码后，我将在重构/测试中进行几次传递。我只是想知道是否有人对如何使这个过程更容易/更有效有任何提示。

做错了

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

首先编写一些测试来验证您正在查看的位实际上在做什么。然后重构。这比“看起来它仍然有效”要可靠得多。

这样做的另一个巨大好处是，当您重构页面下方或共享库或其他内容时，您可以重新运行测试，而不是找出看似无关的困难方式变化实际上是相关的

score 1 · Accepted Answer

您要从经典的 ASP 到 3.5 的 ASP，而无需重新编写？技能。我不得不处理一些遗留的 ASP @work，我认为解析它并重新编写它更容易。

score 1 · Accepted Answer

一个 1500 行的 ASP 页面？有很多调用来包含文件？不要告诉我——这些函数没有任何命名约定来告诉你哪个包含文件有它们的实现......这会带回记忆（不寒而栗）......

在我看来，你有一个非常可靠的方法——我不确定是否有任何神奇的方法可以减轻你的痛苦。在您进行转换之后，您的应用程序的架构仍然会很混乱且 UI 很重（即代码隐藏运行的工作流程），并且维护起来可能仍然相当痛苦，但是您正在进行的重构肯定会有所帮助。

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

祝你好运！

score 0 · Accepted Answer

听起来你对事情的处理能力相当不错。我见过很多人试图做一个直线音译，包括和所有，它就是行不通。您需要对 ASP.Net 的工作方式有一个很好的了解，因为它与 Classic ASP 有很大的不同，而且听起来您可能已经掌握了这一点。

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

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

score 0 · Accepted Answer

不要告诉我——这些函数没有任何命名约定来告诉你哪个包含文件有它们的实现......这会带回记忆（不寒而栗）......

你怎么猜的？;)

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

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

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

实际上，我对使用遗留代码有相当多的不满，因此我对系统有相当高的理解。您对函数长度是正确的，有一些例程（大多数我已经重构为更小的例程）是新站点上任何 aspx 页面/帮助程序类/ORM 的 3-4 倍。

score 0 · Accepted Answer

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

score 0 · Accepted Answer

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

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

asp.net - 从 ASP Classic 迁移到 .NET 并减轻痛苦

8 回答 8

Related

Reference