我们正在用.NET 3.5重新设计网站中面向客户的部分。到目前为止一切都很顺利，我们使用相同的工作流程和存储过程，在大多数情况下，最大的变化是UI、ORM（从字典到LINQ），显然还有语言。到目前为止，大多数页面都很琐碎，但现在我们正在处理最繁重的工作流程页面。
我们的offer acceptance部分的主页面有1500行，大约90%是ASP，可能还有1000行是函数调用include。我认为1500行也有点欺骗性，因为我们正在处理这样的gem
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。如果我得到了一个我们没有的函数调用，我会写出定义。
在我完成所有的代码之后，我会做一些重构/测试。我只是想知道是否有人有任何关于如何使这个过程更容易/更有效的提示。
8条答案
按热度按时间6xfqseft1#
相信我，我非常清楚你是从哪里来的..我目前正在将一个大型应用程序从ASP经典迁移到. NET..而且我还在学习ASP.NET！：S（是的，我很害怕！）
我脑子里记住的主要事情是：
这非常像用你的代码玩Jenga：）
祝你好运的项目，任何更多的问题，然后请问：）
bwitn5fc2#
在我完成所有的代码之后，我会做一些重构/测试。我只是想知道是否有人有任何关于如何使这个过程更容易/更有效的提示。
（来源：cartoonstock.com）
通常我不是TDD的爱好者，但在重构的情况下，它确实是要走的路。
首先编写一些测试来验证你所看到的代码块实际上在做什么。然后重构。这比仅仅"看起来它仍然工作"要可靠得多。
这样做的另一个巨大好处是，当您重构页面下方的内容时，或者在共享库中重构内容时，您只需重新运行测试，而不必费力地找出一个看似不相关的更改 * 实际上是 * 相关的
9lowa7mx3#
你要从经典的ASP到3.5版的ASP而不需要重写？技巧。我不得不处理一些遗留的ASP @工作，我认为解析和重写它更容易。
nkcskrwz4#
一个1500行的ASP页面？有很多调用包含文件？不要告诉我--函数没有任何命名约定来告诉你哪个包含文件有它们的实现...这让你回想起来（不寒而栗）...
在我看来，你有一个非常可靠的方法--我不确定是否有什么神奇的方法可以减轻你的痛苦。在你的转换工作之后，你的应用程序的架构仍然会很混乱，UI也很重（即运行工作流的代码隐藏），而且维护起来可能仍然会相当痛苦，但你正在做的重构肯定会有所帮助。
我希望您已经权衡了您正在进行的升级和仅仅从头重写--只要您不打算过多地扩展应用程序，并且您不是维护应用程序的主要责任人，升级一个复杂的基于工作流的应用程序可能比从头重写它更便宜，也是更好的选择。ASP.NET至少应该为您提供更好的机会来提高性能和可伸缩性，从你的问题来看，我想现在讨论这个问题已经太晚了。
祝你好运!
nr9pn0ug5#
听起来你对事情处理得很好。我见过很多人试着做一个直线音译，包括和所有，它只是不工作。你需要有一个很好的理解ASP.NET想要如何工作，因为它是 * 很多 * 不同于经典ASP，它听起来像也许你有。
对于较大的文件，我会尝试先获得一个更高层次的视图。例如，我注意到的一件事是，经典ASP在函数调用方面很糟糕。你可能会阅读一些代码，发现一个函数调用，而不知道它可能在哪里实现。结果，经典的ASP代码往往有很长的函数和脚本，以避免那些讨厌的跳转。我记得看到过一个函数打印出40页！直接解析这么多代码并不有趣。
NET使跟踪函数调用变得更加容易，因此您可以从将较大的代码块分解为几个较小的函数开始。
flseospp6#
不要告诉我--这些函数没有任何命名约定来告诉您哪个include文件有它们的实现......这会勾起回忆（不寒而栗）......
你怎么猜到的？）
我希望您已经权衡了您正在进行的升级和仅仅从头重写--只要您不打算过多地扩展应用程序，并且您不是维护应用程序的主要责任人，升级一个复杂的基于工作流的应用程序可能比从头重写它更便宜，也是更好的选择。ASP.NET至少应该为您提供更好的机会来提高性能和可伸缩性，从你的问题来看，我想现在讨论这个问题已经太晚了。
我们谈过的。根据时间（试图击败竞争对手的网站推出）和资源（基本上是两个开发人员）不把网站从轨道上核武器是有道理的。事情实际上比我预期的要好得多。我们甚至从计划阶段就意识到这段代码会给我们带来最多的问题。你应该看看所涉及的经典ASP页面的修订历史，这是一场大屠杀。
对于较大的文件，我会尝试先获得一个更高层次的视图。例如，我注意到的一件事是，经典ASP在函数调用方面很糟糕。你可能会通读一些代码，发现一个函数调用，而不知道它可能在哪里实现。结果，经典的ASP代码往往有很长的函数和脚本，以避免那些讨厌的跳转。我记得看到过一个函数打印出40页!直接解析这么多代码并不有趣。
实际上我对使用遗留代码很不满意，所以我对系统有一个相当高层次的理解。你对函数长度的看法是对的，有一些例程（大多数我已经重构成更小的）是新网站上任何aspx页面/helper类/ORM的3 - 4倍长。
j91ykkif7#
我曾经遇到过一个从ASP移植过来的.Net应用程序。.aspx页面完全是空白的。为了呈现UI，开发人员在后面的代码中使用了StringBuilder，然后执行了response. write。这将是一个错误的方法！
pdkcd3nj8#
我曾经遇到过一个从ASP移植过来的. Net应用程序。. aspx页面完全是空白的。为了呈现UI，开发人员在后面的代码中使用了StringBuilder，然后执行了response.write。这将是一个错误的方法!
我见过它做的另一种方式，代码背后的网页是空白的，除了声明的全局，然后VBScript是留在ASPX。