迁移经典ASP - Webforms还是ASP.NET MVC？

Question

我正在为我的客户端对经典的ASP应用程序进行一些维护，当我正在浏览ASP时，会想到以下问题 - 将经典ASP应用程序转换为ASP.NET MVC会更容易吗？还是ASP.NET WebForms？

在许多方面，似乎至少ASP的HTML可能更容易转换为MVC，而不是撕掉HTML块并将它们转换为ASP.NET控件，转发器，数据网格等。为ViewState添加处理和逻辑等可能会增加工作量。

我认为我的客户不会要求任何这样的升级，所以这只是理论上的。

让我们假设这个ASP代码编写得非常好（当然并不总是如此），所以真的问题是，设计得最好的ASP站点是否会比WebForms更好地迁移到MVC？

（请注意，我对ASP.NET MVC很新，所以我可能会遗漏一些关键的东西）。

Answer 1

这很大程度上取决于经典asp应用程序的结构。

与HTML混合的服务器标签类似于asp.net mvc，但MVC并不是那么混乱（或者不应该是）。您可以将经典的asp演示代码移动到MVC视图，而不是Web表单。此外，经典的asp应用程序通常是在考虑到Web的无状态的情况下开发的。你的经典asp中可能没有任何东西与postabacks或viewstate相匹配。经典ASP还使用普通的html元素而不是asp.net webform控件。在这些方面，它比MVforms更接近MVC。

如果您不了解asp.net webforms或asp.net mvc，我会说MVC是要走的路。

如果你非常了解webforms并且对MVC了解不多，我会说webforms是可行的方法。

但是，如果您的客户出于某种原因想要重新开发该网站，我会说与MVC一起去。只要您能够交付，我们总是很高兴让客户为您的部分经验开发付费。

另一方面，当我遇到一位希望我在他们的经典asp网站上工作的客户时，我总是吃惊。在每一个案例中，网站都是一团糟。更糟糕的是，它们通常充满了巨大的安全漏洞。

Answer 2

我认为在很多情况下，转换为MVC比Webforms更容易。大多数经典ASP应用程序几乎没有关注点分离，因此最大的任务可能就是将数据访问，业务逻辑，业务实体和UI组件分离出来。在这样做时，可以更容易地将内联ASP代码转换为视图，将业务逻辑转换为控制器，将业务实体转换为模型。

Answer 3

我认为一个人转换比另一个人更容易。

如果您希望在aspx中可以访问的代码隐藏中放入一些关键元素，那么您可以编写与编写ASP几乎相同的ASP.NET代码。没有数据绑定，没有gridview，也没有转发器。视图状态可以帮助您轻松搞清楚，如果您不想要它就没有必要使用它，可以在web.config中关闭并打开页面属性。 Web表单还具有 AspCompat 模式，允许访问Request和Response对象或asp，如果需要，可以进行逐页转换。

对于MVC.net，显示HTML的方法非常相似。在我看来，这是相似之处的结束。您仍然需要将所有逻辑分离到MVC模型中。

来自ASP并转到Web.Form和现在的MVC.Net我可以告诉你，WebForms有点烦人/令人沮丧的学习，90％的MS教程教你最坏的习惯IE（SQL连接上页面，在设计器中拖动数据集）。然而，一旦你越过那个人能够更快地完成很多事情然后在asp（分页或构建一个简单的数据表，例如编辑），我仍然没有看到一个带有n层的大型webforms项目我认为很容易遵循，实施和使用的设计。

MVC.NET就像天赐之物。它强迫你的模式和做法扼杀你的喉咙，它有严格的规则，大多数人遵守。它允许简单的代码覆盖和关注点分离。多年来，在对webforms感到沮丧之后，最终感觉我在尝试做一些我无法拖出工具栏的事情时并没有将事情搞混在一起。

我个人会尝试使用webforms，这样当你开始使用它时你就会知道MVC有多好。

Answer 4

ASP.NET-MVC比视图代码和ASP内联代码之间的明显相似性还要多。需要考虑的所有模型和控制器部分与大多数ASP的编写方式都有很大不同。

那就是说我会说MVC是最好的起点。

Answer 5

IMO WebForms尝试过多地隐藏html，并且由于将大量html转换为webforms控件，可能会导致您的项目花费的时间超过您想要的时间。

另一方面，MVC允许您重用一些逻辑，同时使您的应用程序更易于维护，并且使用适当的架构模式，您的应用程序可以比任何WebForms项目更快地开发和重构。

我一直说MVC！

Answer 6

无论哪种方式，最好始终从头开始并仅实现逻辑。

我很久以前就开始使用ASP（超过12年前），直到2006年我才转向使用ASP.NET 2.0，即使在今天我也不知道所有，但我确实知道我每天在工作中做的事情。 / p>

在我看来，回顾我对ASP的了解，我会去Web Forms而不是MVC，首先，它是一种语言，它现在在“市场”中，现在已经在全世界范围内使用，而MVC仍处于测试阶段，因此不适合生产环境（微软表示 - 即使该网站是用MVC编写的）。

我确实倾向于混淆MVC图表，如果我需要快速更改一个ASP项目，还有比我想要学习更多的技巧。

Answer 7

这取决于。 ASP.NET MVC不是灵丹妙药，在许多方面在开发人员生产力方面向后退了一步。

如果您的预算紧张并需要快速完成，我相信ASP.Net是可行的方式，因为它具有丰富的控件，如网格，分页，验证等，您可以立即使用。使用这些控件无疑会节省大量的开发时间。目前在ASP.NET中大多数考虑行人的所有这些控件都必须从头开始创建，或者在使用ASP.NET MVC项目时从Internet获取。

另一方面，如果您现在有时间和预算，并且希望有一个坚如磐石的解决方案，并且更容易适合测试驱动开发，那么ASP.NET MVC可能是最好的选择。

Answer 8

绝对ASP.NET MVC在风格方面更胜一筹。 （也就是说，你没有 在WebForms应用程序中使用Repeater和其他愚蠢的控件，你可以简单地使用内联代码，就像在MVC中一样。）< / p> 总的来说，MVC将是一个更容易的端口，为您提供更好的结构，让您获得更愉快的体验。

Answer 9

Web窗体更面向对象，而MVC就像.NET代码之上的经典ASP一样。使用Web窗体或MVC，模型设计应该是相同的。唯一的区别是Web Forms对UI有一个面向对象的抽象，MVC使用函数和代码片段而不是类来组织UI代码。

Answer 10

ASP.NET MVC比Web Forms更适合用于UI的自动单元测试。但是，自动单元测试通常是不好的做法，对UI来说更糟糕。手动测试是构建高质量应用程序和充分利用开发时间的最佳方式。创建自动化单元测试是浪费时间，最终使用垃圾代码来维护核心代码。许多开发人员喜欢自动化单元测试，因为他们认为他们证明了他们的应用程序有效，这是错误的。他们还试图避免使用UML设计应用程序，因此他们使用测试驱动开发来设计使用负责设计不佳的应用程序的代码。使用TDD，您可以重构您编写的代码，而不必考虑使用模型的大局。

所以MVC没用。 Web窗体使用更好的面向对象模型，而MVC更像旧式经典ASP和其他旧设计模式。这是2010年，MVC已经死了。 Web窗体就像用户界面的ORM。