我正在为我的客户端对一个经典 ASP 应用程序进行一些维护，当我查看 ASP 时，我想到了以下问题 - 将经典 ASP 应用程序转换为 ASP.NET MVC 是否更容易还是 ASP.NET WebForms？
在许多方面，似乎至少 ASP 的 HTML 可能更容易转换为 MVC，而不是撕掉 HTML 块并将它们转换为 ASP.NET 控件、转发器、数据网格等。另外还有添加 ViewState 的处理和逻辑等可能会添加工作。
我认为我的客户不会要求这样的升级，所以这只是理论上的。
让我们假设这个 ASP 代码写得很好（当然这并不总是正确的）所以问题是，一个最佳案例设计良好的 ASP 网站会比 WebForms 更好地迁移到 MVC 吗？
（请注意，我对 ASP.NET MVC 还很陌生，所以我可能在这里遗漏了一些重要的东西）。
【问题讨论】：
标签： asp.net asp.net-mvc asp-classic
这在很大程度上取决于经典的 asp 应用程序的结构。
与 HTML 混合的服务器标签类似于 asp.net mvc，但 MVC 没有那么混乱（或不应该如此）。您可能能够将经典的 asp 演示代码移至 MVC 视图，而不是移至 Web 表单。此外，经典的 ASP 应用程序通常在开发时考虑到 Web 的无状态性。您的经典 asp 中可能没有任何内容与 postabacks 或 viewstate 匹配。 Classic ASP 也使用普通的 html 元素，而不是 asp.net webform 控件。在这些方面，它与 MVC 的匹配度比 webforms 更接近。
如果你不知道 asp.net webforms 或 asp.net mvc 我会说 MVC 是要走的路。
如果您非常了解网络表单，但对 MVC 了解不多，我会说网络表单是您的最佳选择。
但是，如果您的客户出于某种原因确实想要重新开发网站，我会建议您选择 MVC。只要您可以交付，让客户为您的部分体验开发付费总是很好的。
另一方面，当我遇到一个希望我在他们的经典 asp 网站上工作的客户时，我总是很吃惊。在每种情况下，该网站都是一团糟。更糟糕的是，它们通常充满了巨大的安全漏洞。
【讨论】：
我认为在很多情况下，转换为 MVC 可能比 Webforms 更容易。大多数经典的 ASP 应用程序很少展示关注点分离，因此最大的任务可能就是这样，将逻辑分离为数据访问、业务逻辑、业务实体和 UI 组件。这样做很容易将内联 ASP 代码转换为视图，将业务逻辑转换为控制器，将业务实体转换为模型。
【讨论】：
我不认为一个会比另一个更容易转换。
如果您想在代码隐藏中放置一些您可以在 aspx 中访问的关键元素，您几乎可以像编写 ASP 一样编写 ASP.NET。没有数据绑定，没有网格视图，也没有中继器。视图状态可以帮助您很容易弄清楚，如果您不想使用它，则无需使用它，可以在 web.config 中关闭并使用页面属性打开。 Web 表单还具有 AspCompat 模式，该模式允许访问请求和响应对象或 asp，如果需要，这将允许逐页转换。
对于 MVC.net，显示 HTML 的方法非常相似。在我看来，这就是相似之处的结束。您仍然需要将所有逻辑分离到 MVC 模型中。
从 ASP 到 Web.Form 和现在的 MVC.Net 我可以告诉你，WebForms 学习起来有点烦人/令人沮丧，90% 的 MS 教程教你最坏的习惯 IE（SQL 连接页面，在设计器中拖动数据集）。但是，一旦你超越了这一点，它能够比在 asp 中更快地完成很多事情（例如，分页或通过编辑构建一个简单的数据表），但是我仍然从未见过具有 n 层的大型 webforms 项目我认为易于遵循、实施和使用的设计。
MVC.NET 就像天赐之物。它迫使你的模式和实践进入你的喉咙，它有大多数人都遵守的严格规则。它允许轻松的代码覆盖和关注点分离。在对网络表单感到沮丧多年之后，当我尝试做一些我无法从工具栏上拖下来的事情时，我终于觉得我并没有把事情拼凑在一起。
我个人会尝试使用网络表单，这样当您开始使用 MVC 时，您就会知道它有多好。
【讨论】：
除了视图代码和 ASP 内联代码之间的明显相似性之外，ASP.NET-MVC 还有更多。需要考虑所有模型和控制器部分，这与大多数 ASP 的编写方式非常不同。
也就是说，我会说 MVC 将是最好的起点。
【讨论】：
IMO WebForms 试图隐藏太多我喜欢的 html，并且由于将大量 html 转换为 webforms 控件，可能会导致您的项目花费比您希望的更长的时间。
另一方面，MVC 允许您重用其中的一些逻辑，同时使您的应用程序更易于维护，并且使用适当的架构模式，您的应用程序可以比任何 WebForms 项目更快地开发和重构。
我一直说MVC！
【讨论】：
无论如何，最好从头开始，只实现逻辑。
很久以前（超过 12 年前）我开始使用 ASP，直到 2006 年我才迁移到 ASP.NET 2.0，即使在今天我也不知道全部，但我确实知道我每天在工作中所做的事情。
在我看来，现在回顾我对 ASP 的了解，我会使用 Web 表单而不是 MVC，首先，它是一种语言，它现在已经在“市场”中出现了一些年，并且在世界范围内非常使用，而MVC 仍处于 Beta 阶段，因此不适合生产环境（Microsoft 说 - 即使这个网站是用 MVC 编写的）。
我仍然倾向于混淆 MVC 图，如果我需要对一个 ASP 项目进行快速更改，我想学习的技巧比我想学习的要多。
【讨论】：
这取决于。 ASP.NET MVC 不是灵丹妙药，在许多方面在开发人员生产力方面都落后了几步。
如果您的预算紧张并且需要快速完成这项工作，我相信 ASP.Net 是不错的选择，因为它具有丰富的控件，例如网格、分页、验证等，您可以直接使用这些控件。使用这些控件无疑会节省大量的开发时间。当您使用 ASP.NET MVC 项目时，所有这些目前在 ASP.NET 中被认为是普通的控件都必须从头开始创建或从 Internet 获取。
另一方面，如果您现在和未来有时间和预算，并且想要一个坚如磐石的解决方案，并且更容易适合测试驱动的开发，那么 ASP.NET MVC 可能是最好的选择。
【讨论】：
毫无疑问，ASP.NET MVC 在风格方面更好。 （也就是说，您没有必须在 WebForms 应用程序中使用中继器和其他愚蠢的控件，您可以像在 MVC 中一样简单地使用内联代码。）
一般来说，MVC 会更容易移植，为您提供更好的结构和更愉快的体验。
【讨论】：
Web Forms 更加面向对象，而 MVC 类似于 .NET 代码之上的经典 ASP。使用 Web 表单或 MVC 的模型设计应该相同。唯一的区别是 Web 窗体对 UI 有一个面向对象的抽象，而 MVC 使用函数和代码 sn-ps 而不是类来组织 UI 代码。
【讨论】：
ASP.NET MVC 在 UI 的自动化单元测试方面优于 Web 窗体。然而，自动化单元测试通常是不好的做法，对 UI 来说更糟。手动测试是构建高质量应用程序和充分利用开发时间的最佳方式。创建自动化单元测试是浪费时间，并且最终会使用垃圾代码来维护核心代码。许多开发人员喜欢自动化单元测试，因为他们认为它们证明了他们的应用程序可以工作，这是错误的。他们还试图避免使用 UML 设计应用程序，因此他们使用测试驱动开发来使用导致设计不佳的应用程序的代码进行设计。使用 TDD，您可以重构编写不佳的代码，而无需首先考虑使用模型的全局。
所以 MVC 没用。 Web Forms 使用更好的面向对象模型，而 MVC 更像旧式经典 ASP 和其他旧式设计模式。这是 2010 年，MVC 已经死了。 Web 表单就像 UI 的 ORM。
【讨论】：