从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经典的耦合量极高往往会有，这将是非常危险的。当然，如果你有信心，请填补你的靴子:)这可以随后重构。
• 通过测试，测试和更多测试来支持所有内容！我真的很努力进入TDD，但它很难测试现有的应用程序，因此每次我删除一大块经典并替换为.NET时，我确保尽可能多的绿灯测试支持我。< / LI>
• 研究很多，经典版和.NET版之间有一些主要的变化，有时可以在几行代码中实现多行代码和包含的代码，在编码之前思考 ..我已经多次学到了这一点：D

非常喜欢用你的代码玩Jenga：）

祝好项目，还有更多问题，请问：）

Answer 2

  

在我完成所有编码之后，我会在重构/测试中做一些通行证。我只是想知道是否有人有任何关于如何使这个过程更容易/更有效的提示。

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

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

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

Answer 3

你是不是只重写了，从3.5经典ASP到ASP？的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.NET应该会让你更好   提高绩效的机会   和可扩展性，至少，比   经典ASP。从你的问题我   想象一下，为时已晚   无论如何，这个讨论的过程。

这是我们谈到的。基于时机（试图击败竞争对手的网站发布）和资源（基本上是两个开发人员），有意义的是不从轨道上攻击网站。事情实际上比我预期的要好得多。我们甚至从计划阶段就知道这段代码会给我们带来最多的问题。你应该看到所涉及的经典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中。