我们正在重新设计.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的过程中进行明显的重构。如果得到了我们没有的函数调用，我将写出定义。

编写完所有代码后，我将进行一些重构/测试。我只是想知道是否有人对如何使此过程更简单/更有效有任何建议。

解决方案

回答

我们要从经典的ASP转换为带有3.5的ASP，而无需重新编写？ Skillz。我不得不处理一些遗留的ASP @work，我认为解析并重新编写它更容易。

回答

After I have everything coded I'll do a few passes at refactoring/testing. I'm just wondering if anyone has any tips on how to make this process a little easier/more efficient.

通常我不喜欢TDD，但是在重构的情况下，这确实是可行的方法。

首先编写一些测试，以验证我们正在查看的内容实际上在做什么。然后重构。这比"看起来仍然有效"要可靠得多。

这样做的另一个巨大好处是，当我们重构页面下方或者共享库中的内容时，只需重新运行测试即可，而不是找出看似无关的困难方法。变化实际上是相关的

回答

相信我，我确切地知道来源。.我目前正在将大型应用程序从ASP Classic迁移到.NET。而且我仍在学习ASP.NET！ ：S(是的，我很害怕！)。

我想到的主要内容是：

• 由于ASP classic往往具有大量的耦合，因此我不会偏离当前的设计(即，不会出现大量的"使所有这些都消失，使ASP.NET变得神奇！")，这将是非常危险的。当然，如果我们有信心，可以加满靴子:)以后可以随时重构它。
• 通过测试，更多测试来备份所有内容！我确实尽力尝试使用TDD，但是要测试现有应用程序非常困难，因此，每次删除大量经典代码并替换为.NET时，我都会确保有尽可能多的绿色测试支持我。
• 大量研究发现，经典和.NET之间存在一些重大变化，有时可以在几行代码中实现很多代码，包括在经典代码中，请在编码之前进行思考。 ，好几次：D

这非常像用代码玩Jenga :)

祝项目顺利，如有其他问题，请提问:)

回答

听起来我们对事物的处理能力很好。我已经看到很多人尝试进行直线音译，包括所有内容，但这是行不通的。我们需要对ASP.Net的工作方式有一个很好的了解，因为它与经典ASP有很大的不同，而且听起来好像我们已经掌握了。

对于较大的文件，我将尝试首先获取更高级别的视图。例如，我注意到的一件事是，经典ASP对于函数调用来说太可怕了。我们将通读一些代码并找到对函数的调用，而对其执行位置一无所知。结果，Classic ASP代码倾向于具有长函数和脚本来避免那些讨厌的跳转。我记得看到一个打印到40页的功能！直接解析那么多代码并不有趣。

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

回答

1500行的ASP页？有很多电话要包含文件吗？不要告诉我-函数没有任何命名约定，可以告诉我们哪个include文件具有其实现...这会带回内存(颤抖)...

在我看来，方法很扎实-我不确定是否有任何神奇的方法可以减轻痛苦。进行转换工作之后，应用程序架构仍将杂乱无章且UI繁重(即，在运行工作流的代码背后)，并且维护起来仍然很痛苦，但是我们进行的重构肯定会有所帮助。

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

祝你好运！

回答

Don't tell me -- the functions don't
  have any naming convention that tells
  you which include file has their
  implementation... That brings back
  memories (shudder)...

你怎么猜的？ ;)

I hope you have weighed the upgrade
  you are doing against just rewriting
  from scratch -- as long as you are not
  intending to extend the app too much
  and you are not primarily responsible
  for maintaining the app, upgrading a
  complex workflow-based app like you
  are doing may be cheaper and a better
  choice than rewriting it from scratch.
  ASP.NET should give you better
  opportunities to improve performance
  and scalability, at least, than
  Classic ASP. From your question I
  imagine that it is too late in the
  process for that discussion anyway.

这是我们谈论的事情。基于时间安排(试图击败竞争对手的网站进行发布)和资源(基本上是两个开发人员)，不要从轨道上挪动该网站是有意义的。实际上情况比我预期的要好得多。我们甚至从计划阶段就意识到，这段代码将给我们带来最多的问题。我们应该看到所涉及的经典ASP页面的修订历史，这真是令人难以置信。

For larger files, I'd try to get a
  higher level view first. For example,
  one thing I've noticed is that Classic
  ASP was horrible about function calls.
  You'd be reading through some code and
  find a call to a function with no clue
  as to where it might be implemented.
  As a result, Classic ASP code tended
  to have long functions and scripts to
  avoid those nasty jumps. I remember
  seeing a function that printed out to
  40 pages! Parsing straight through
  that much code is no fun.

实际上，我对使用遗留代码有很多不满意，因此我对系统有很高的了解。我们对函数的长度是正确的，有一些例程(大多数我将其重构为更小的例程)是新站点上任何aspx页面/帮助程序类/ ORM的3-4倍。

回答

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

回答

I once came across a .Net app that was ported from ASP. The .aspx pages were totally blank. To render the UI, the developers used StringBuilders in the code behind and then did a response.write. This would be the wrong way to do it!

我已经看到了它的另一种用法，页面后面的代码为空白，除了声明全局变量外，然后将VBScript留在了ASPX中。