C# 将经典ASP应用程序转换为ASP.NET有哪些有用的策略

我们有一个10年的ASP应用程序，我们正在考虑计划更新。我们希望利用ASP.NET提供的新技术，以及修复现有框架的一些问题的机会（现有代码库高度分散，几乎不可能进行测试，更不用说调试了，整个应用程序似乎是根据“农舍模式”构建的）

为此，似乎是时候重建这个应用程序了。但是，我们是一家小型企业，我们根本没有资源来出租重建，也没有资源将我们的小型开发团队专门用于重建任务（我们还有其他任务要做，不能在完全重建应用程序所需的时间内专注于这一特定任务）

---

那么，我们可以采用哪些有用的策略来帮助我们转换此应用程序，而不会让它在重写期间消耗我们所有有限的资源

听起来是个有趣的挑战。这绝对不是一件容易的事，尤其是如果你不能全天投入任何资源来完成这个项目

如果你有一个已经运行了10年的应用程序，我建议你完全不要重新编写。我会先坐下来，弄清楚你想要的最终产品是什么

---

它将是ASP.NET MVC Web应用程序、ASP.NET WebForms应用程序还是其他应用程序？一旦做出了这个决定，就为架构提出一个宽松的设计。如果操作正确，您可以在.NET中构建业务逻辑的各个部分，并从经典的ASP代码中使用它，直到您准备在.NET中重新编写UI。

对我来说唯一有效的方法是将功能区域划分成小块，然后重写。先是“转换”，然后重构几次似乎是个好主意，但最后变成了用ASP.NET而不是ASP编写的可怕的代码混乱——这没有增加任何价值

如果你有一个网站有不同的功能领域，那么就从这个领域开始（我选择了“联系我们”）。用你认为应该写的方式写——也就是说，假设你的新部件适合你写得很好的应用程序的最终设计。如果您必须添加“黑客”与旧系统的接口，请确保它们是隔离的并有注释的

在进行更新时，请思考“我可以将这里的一些功能划分为它自己的一部分吗？”——如果可以，请将其转换，然后进行更新。我发现，如果你坚持保持新应用程序的整洁，允许自己在旧应用程序中添加一些小技巧进行交流，你会得到最好的结果

这意味着您将有两个单独的应用程序（两个IIS web应用程序）存在一段时间，这可能会使cookie/url和会话管理有点麻烦，并且还会增加一个部署问题。要解决这一问题，请确保最小化web应用程序中的状态（无论如何，这始终是个好主意），并通过

会话

以外的其他方式共享状态

如果你一次做一件，把它做得足够小，并且事先有一个好的设计，这很好——至少在我的经验中，这是最有效的方式。请注意，我的经验可能与现实不符。

我同意什么；如果您有一个可用的应用程序，那么您需要一个令人信服的理由（即金钱）来证明为新平台重写应用程序的费用是合理的

尽管ASP classic和ASP.NET有着相似的语法和一些常见的编码约定，但它们之间有着很大的不同。如果您试图简单地将经典ASP代码复制粘贴到ASP.NET应用程序中，您可能能够使其正常工作，但您可能会错过ASP.NET Web窗体或ASP.NET MVC（当然还有它们各自的框架）的许多优点

---

但是，您可以通过web服务或COM互操作使用.NET代码扩展现有站点的功能。我们有一个10多年的经典ASP网站，我使用了.NET web服务（.asmx）和COM可调用的.NET DLL来增强我们现有的应用程序。在这两种情况下，我都在.NET组件中编写了所有新的业务逻辑，并提供了一个笨重的界面来处理现有的ASP页面。这使得我的.NET代码非常容易测试，并且仍然使用我们在经典ASP网站上的现有（巨大）投资。

农舍模式是什么？嘿，这是一个伟大的“可视化”。。。你从一个小小的庇护所（最初的核心应用程序）开始，然后，多年来，在这里（一个新模块）加上一个新房间，在那里加上一个，也许几年后我们会在第二层加上一个（整个新的“功能层”与核心应用程序不完全相关），然后我们发现他们之间需要一个楼梯。四壁+屋顶=农舍。在这里添加一块板，在那里添加一块板。。。太好了，你去过中西部吗？他们从一间卧室、一间小厨房、一间客厅和一间厕所开始。然后，他们想到如果厕纸不总是冻着的话会很酷，所以他们在厨房里加了一个浴室。然后，由于极端的计划生育，厨房变得太小了。于是，他们在厨房里加了一个。然后，踏进客厅的泥泞和牛粪的靴子没有那么热，所以他们增加了一个泥泞的房间。然后。。。是的，这就是农舍的模式。不确定它是否在“设计模式”中。