从ASP Classic迁移到.NET并缓解疼痛
我们正在.NET 3.5中重新设计我们网站中面向客户的部分。目前为止，我们使用相同的工作流和存储过程，其中最大的变化是UI，ORM（从字典到LINQ），显然是语言。目前大多数页面都是微不足道的，但现在我们正在处理最重的工作流页面。从ASP Classic迁移到.NET并缓解疼痛
我们的报价接受部分的主页是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。如果我得到一个我们没有的函数调用，我会写出这个定义。
在我编写了所有代码之后，我会在重构/测试中做一些传递。我只是想知道如果任何人有任何提示，如何使这个过程更容易/更有效。
相信我，我知道确切其中你是从哪里来的..我目前迁移从ASP经典到.NET的大型应用程序。而我仍然在学习ASP 。净！ ：S（是的，我很害怕！）。
我一直在我脑海里的主要事情是这样的：
- 我不杂散太远离当前设计（即没有出现大规模“让撕了这一切并使其ASP.NET不可思议的！）由于ASP经典版本的耦合量非常高，所以这会非常危险。当然，如果你有信心，请填写你的靴子:)以后总是可以重新构建这些东西
- 与测试，测试和更多测试！我真的很难进入TDD，但它很难测试现有的应用程序，所以每次我删除一大块经典代码并用.NET代替时，我确保我有尽可能多的支持绿灯的测试。
- 研究很多，经典和.NET之间有一些主要的变化，有时候可以是许多代码行，包括经典的可以在几行代码中实现，认为在编码之前。这种痛苦的滋味，几次：d
它非常喜欢打Jenga与您的代码:)
最佳运气的项目，更多的问题，那么请咨询:)
你将从传统的ASP到3.5的ASP而不只是重写？的skillz。我不得不处理一些传统的ASP @work，我认为解析它并重写它更容易。
当我编码完成所有事情之后，我会在重构/测试中做几个通过。我只是想知道如果任何人有任何提示，如何使这个过程更容易/更有效。
通常我不是TDD的粉丝，但在真正重构它的情况是要走的路。
先写一些测试来验证你正在看的位是在做什么。然后重构。这比LOT更可靠，它看起来仍然有效。
另一个巨大的好处是，当你重构更深层页面或共享库或其他东西时，你可以重新运行测试，而不是找出困难的方式一个看似无关的变化被实际上与
听起来像你有一个很好的处理事情。我看到很多人试图做直线音译，包括所有，而且它不起作用。您需要对ASP.Net的工作原理有一个很好的理解，因为它的的与传统的ASP不同，听起来也许你有这个想法。
对于较大的文件，我会尝试先获得更高级别的视图。例如，我注意到的一件事是，经典的ASP对函数调用来说太可怕了。你会阅读一些代码，并找到一个函数的调用，而不知道它可能在哪里实现。因此，经典ASP代码倾向于具有较长的函数和脚本以避免这些讨厌的跳转。我记得看到一个打印到40页的功能！直接解析这么多的代码并不好玩。
ASP.Net可以更轻松地跟踪函数调用，因此您可以先将较大的代码块分解为几个较小的函数。
一个1500行的ASP页面？有很多电话打包文件？不要告诉我 - 功能没有任何命名约定，告诉你哪个包含文件有他们的实现...这带来回忆（不寒而栗）...
这听起来像我喜欢你有一个非常可靠的方法 - 我不确定是否有任何神奇的方法来减轻你的痛苦。在您的转换工作完成后，您的应用程序的体系结构仍然很混乱，并且会占用大量UI（即，代码隐藏的正在运行的工作流程），并且可能仍然很难维护，但您所做的重构肯定会有所帮助。
我希望您已经权衡了您正在从头开始重写的升级 - 只要您不打算扩展应用程序太多，并且您不主要负责维护应用程序，升级复杂的工作流程，像你正在做的基于应用程序的应用程序可能比从零开始重写它更便宜和更好的选择。至少，与ASP.NET相比，ASP.NET应该为您提供更好的机会来提高性能和可伸缩性。从你的问题来看，我认为在讨论过程中已经太迟了。
祝你好运！
不要告诉我 - 的功能不 有任何命名约定，告诉你 包括文件都有自己的 实现......这勾起回忆 （战栗）...
你是怎么猜到的？;）
我希望你权衡你做对从头开始重写刚在 升级 - 只要你不打算 延长应用程序太多 ，你是不是主要负责 维护应用程序，升级 复杂的基于工作流程的应用程序，如 正在做的可能比从零开始重写它更便宜并且更好 选择。 ASP.NET应该给你提供更好的机会来提高性能 和可扩展性，至少比经典ASP的 。从你的问题I 想象，无论如何，这个讨论的 过程已经太迟了。
这是我们谈到的。基于时机（试图击败竞争对手的网站发布）和资源（基本上是两个开发人员），不要将该网站从轨道上移开是有意义的。事情实际上比我预期的要好得多。我们甚至从计划阶段就知道这个代码会给我们带来最多的问题。你应该看到涉及的经典ASP页面的修订历史，这是一场血洗。
对于较大的文件，我会试着首先得到一个 更高级别的视图。例如， 我注意到的一点是，经典的 ASP对于函数调用来说太可怕了。 你会阅读一些代码和 找到一个函数的调用，不知道它可能实现的地方。 因此，经典ASP代码倾向于 具有长功能和脚本，以避免那些讨厌的跳跃。我记得 看到一个功能，打印到 40页！直接解析 那么多代码就没有趣味。
实际上，我对遗留代码的工作有点不满，所以我对系统有很高层次的理解。你对函数的长度是正确的，有一些例程（大多数我已经重构为更小的例程），这些例程与新站点上的任何aspx页面/辅助类/ ORM一样长3-4倍。
我曾经遇到过一个从ASP移植过来的.Net应用程序。 .aspx页面完全空白。为了呈现UI，开发人员在代码背后使用了StringBuilders，然后执行了response.write。这将是错误的做法！
我曾经遇到过一个从ASP移植过来的.Net应用程序。 .aspx页面完全空白。为了呈现UI，开发人员在代码背后使用了StringBuilders，然后执行了response.write。这将是错误的做法！
我已经看到它做了另一种方式，页面后面的代码是空白的，除了全局声明，然后VBScript留在ASPX。