我们有一个已有十年历史的ASP应用程序正在考虑计划更新。我们希望利用ASP.NET提供的新技术，以及修复现有框架的一些问题的机会（现有的代码库高度分散，几乎无法测试，更不用说调试了，以及整个应用程序似乎是根据“农舍模式”构建的。）
为此，似乎现在是重建此应用程序的时候了。但是，我们是一个小企业，我们根本没有资源来支持重建，也没有把我们的小团队开发人员专门用于重建任务（我们已经完成了其他任务，并且在完全重建应用程序所需的时间内，不能专注于这一特定任务。）
然后，我们可以采用哪些有用的策略来帮助我们转换此应用，而不会在重写期间消耗掉所有有限的资源？
答案 0 :(得分：2)
听起来像是一个有趣的挑战。这绝对不容易，特别是如果你不能全职投入任何资源。
如果你有一个10年的应用程序正在运行，我建议不要完全重写。我会先坐下来弄清楚你想要的最终产品是什么。
它将成为ASP.NET MVC Web应用程序，ASP.NET WebForms应用程序还是其他什么？做出决定后，为架构设计一个松散的设计。如果你正确地做了事情，你可以在.NET中构建业务逻辑的一些部分，并从你的经典ASP代码中使用它，直到你准备在.NET中重新编写UI。
答案 1 :(得分：1)
我同意Justin said的内容;如果你有一个有效的应用程序，你需要一个令人信服的理由（即 money ）来证明重写新平台应用程序的费用。
虽然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站点中的现有（巨额）投资。
答案 2 :(得分：0)
对我有用的唯一方法是在小切片中雕刻功能区域并重写。首先是“转换”，然后重构几次似乎是一个好主意，但最终只是变成了用ASP.NET编写而不是ASP编写的可怕的代码 - 并且没有增加任何价值。
如果您的网站具有不同的功能区域，请将其关闭并从中开始（我选择“与我们联系”）。按照您认为应该编写的方式编写它 - 也就是说，假设您的新部分适合您编写良好的应用程序的最终设计。如果您必须添加“hacks”以与旧系统连接，请确保它们已被隔离并注释。
在进行更新时，请考虑“我可以将其中的某些功能划分到它自己的位置吗？” - 如果是这样，转换它然后更新它。我发现，如果你坚持让新应用程序保持干净并允许自己在OLD应用程序中添加小黑客进行通信，那么你将获得最佳结果。
这意味着你有一段时间会有两个独立的应用程序（两个IIS网络应用程序），并且可以使cookie / url和会话管理有点毛茸茸，以及增加一个部署问题。要解决这个问题，请确保您最小化网络应用中的状态（无论如何总是一个好主意），并通过Session以外的其他方式共享状态。
如果你一次做这件事，把它做得足够小，并且预先设计好，这很有效 - 至少在我的经验中，这是最好的方式。请注意，我的经历可能与现实不符。