经典ASP到ASP.net或ASP.net MVC

我们有一个使用经典ASP开发的Web应用程序，它经过5年的发展演变成目前的形式，该应用程序具有100多个页面，庞大的数据库和10000个活跃用户，每天至少浏览10个页面。

现在，我们想将其升级到最新版本的.net。最初我们考虑重写整个应用程序，但是在分析了场景之后，我们发现这不是一个可行的选择，很多专家也没有建议。我们还没有决定如何做，但是对如何实现面部改写有些想法。

选项1： 我们考虑了识别此应用程序中的主要模块，并通过将应用程序划分为不同的层（如数据库（现有），业务逻辑和视图）来逐一重写它们。这样，新开发的模块将被添加到现有系统中，而新页面将替换该特定模块中的旧页面。同时，我们可以与旧系统一起测试新层，并在我们确信后释放它们。我们还考虑过开发用于业务逻辑的API类型的结构，并将其作为外部应用程序进行访问。

选项2： 目前，我们已经完成了一个简单的模块，并通过IFrame在经典ASP页面中使用了它，尽管在经典ASP和IFrame中的新页面之间发送数据非常麻烦。

这只是在计划阶段，我们将如何实现整个应用程序的重写而又不打扰用户群。

我想征询其他程序员的意见，意见和建议，以应对这种情况？如果有人遇到过这种情况，请也分享您的看法。

还想知道使用ASP.net MVC在这方面对我有帮助吗？

更新：感谢您提供观点的两个答案。在将应用程序从经典ASP迁移到asp.net或asp.net mvc时，我想在上面指定的两个选项上获得更多输入。如果你们都可以通过您对迁移部分的观点，观点和想法，而不是选择asp.net或asp.net mvc的观点，那对我将是极大的帮助。

首先，我要说：“我感到你的痛苦，布鲁萨。” 我经历了3年前，我希望MVC在那时已经成熟，因为我设计的WebForms解决方案非常类似于MVC模型，而实际上并没有为我构建Microsoft库（当然，有几个明显的“为什么我是否做到了”差异）。

我还最终使用iFrames来管理内容差异，其中以.Net作为父级应用程序，而将经典asp作为从属程序。我在.Net中开发了框架架构，并实现了该架构。然后，将经典的ASP页面“剔除”掉不必要的演示文稿（包括和诸如此类），并加载到iFrame中。然后，使用自定义加密通过url传递数据。为确保身份验证不容易被欺骗，并通过破解查询字符串来访问页面，我们还在IIS中采用了通配符处理程序，该函数在解析传统的ASP页面之前强制.Net进行身份验证。

鉴于此，我的建议是立即前往MVC。

1. MVC将使您可以访问global.asax级别的路由。通过对控制器的巧妙操纵，您可以以适当的方式开发模型，并拥有一个通用的控制器来处理所有必要的经典asp请求。
2. MVC将使添加测试项目变得非常简单，并允许您基于新的模型结构重构单个应用程序，同时提供足够的测试范围以确保一切正常。这样做的价值是绝对无法估量的，因为在任何重构代码中，覆盖范围都是一个很大的问题。
3. 与WebForms相比，MVC遵循的脚本呈现方式更加脚本化。WebForms尝试将所有内容混合在一起，就像它是某种有状态的应用程序（不是）一样，这对于习惯于经典asp的人们来说可能是一种文化冲击。别误会，无论您采用哪种方式，您的开发人员都会对文化产生震惊，但是如果您可以从表示层中消除这种震惊，那么您可能会找到更大的成功。

我既喜欢WebForms也喜欢MVC（尽管随着Razor的引入我会承认我对MVC有点偏见）。它们都有自己的位置，我认为您所描述的应用程序可能非常适合MVC实现，特别是考虑到在推出重构应用程序部分时需要采用“交错”性质。

无论采用哪种方式，我都需要确保在身份验证/授权/路由/等方面，.Net应用程序始终是父应用程序。我的一位同事在一个以经典asp为父类的类似应用程序上实现了他的迁移，当最终将所有内容重新集成在一起时，他遇到了很多问题。

选择ASP.NET MVC并不一定会使转换变得更加容易，实际上可能会使转换更加困难。但是，当您已经选择要完成这项艰巨的任务时，为什么不花时间继续前进并选择最适合您计划的平台呢？

迁移到ASP.NET（无MVC）将是“容易的”，这意味着您通常可以直接执行现有逻辑的端口，而不必进行大量的重构，前提是您不必使用很多其他操作经典ASP。对于已经熟悉该应用程序的人们来说，结果将是令人满意且相对熟悉的。从将经典ASP移植到ASP.NET的每个应用程序都将受益的意义上，您将获得收益。

迁移到ASP.NET MVC将需要更多工作。可能需要重新配置您的应用程序模型以适合MVC模式。这通常是一件好事（tm），因为它鼓励良好的行为，例如关注点分离。除核心逻辑部分外，最终的应用程序可能与您现有的任何内容都不太相似。您还将获得其他好处。这将是一个巨大的文化转变，并且需要对开发团队进行一些（重新）培训才能正确理解“如何编写MVC”。

值得注意的是，微软并没有根据ScottGu的说法（截至一年前）放弃WebForms，但我认为很难（如果/当他们确实决定逐步淘汰这两种技术之一时） WebForms。

我完全同意ASP.NET MVC是必经之路。这不会很容易，也不会很容易，但是肯定比WebForms有更多的未来证明。尽管WebForms肯定没有被废弃，但是随着应用程序变得越来越大，使用它们的应用程序变得越来越繁琐。

我强烈建议不要在“大型”应用程序上使用WebForms。

我喜欢选项1）（使用MVC）比选择2）好得多，因为它允许您逐步开发应用程序，而不必像使用iFrames方法那样过多地耦合两个应用程序。

我在将旧的应用程序迁移到ASP.Net方面有一些经验，其中的挑战之一是在两个应用程序之间共享一些资源，例如会话状态。可以通过让一个应用程序通过用户浏览器中的cookie信息在服务器端调用另一个应用程序来解决。应用程序之间的其他信息共享当然也可以通过URL路由和查询字符串完成，这是MVC的自然方法。

同样，确定首先要迁移的适当模块也可能是一个挑战，但是您可以从在MVC上开发的所有新功能开始，以防止更多东西最终在车库中迁移。然后，也许选择需要大量返工或错误修复的部分，接下来MVC应用程序将成为重构的一种形式，使用旧系统按照您的建议建立预期的结果。不要忘记通过在重构过程中添加单元测试和自动验收测试（例如SpecFlow / Watin）来利用MVC的可测试性。后一种测试的优点是，您可以验证它们是否通过了旧系统，然后将相同的测试应用于新代码以进行此和将来的重构。