我正在为我的客户端做一些经典ASP应用程序的维护，当我正在浏览ASP时，脑海中浮现出以下问题 - 将经典ASP应用程序转换为ASP.NET MVC或ASP会更容易 . NET WebForms？
在许多方面，似乎至少ASP的HTML可能更容易转换为MVC，而不是撕掉HTML块并将它们转换为ASP.NET控件，转发器，数据网格等 . 另外，必须添加可以添加ViewState等的处理和逻辑 .
我不认为我的客户会要求任何这样的升级，所以这只是理论上的 .
让我们假设这个ASP代码编写得非常好（当然并不总是这样），所以问题是，一个设计最好的ASP站点是否会比WebForms更好地迁移到MVC？
（请注意，我对ASP.NET MVC很新，所以我可能会遗漏一些关键的东西） .
10 回答
这很大程度上取决于经典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网站上工作的客户时，我总是吃惊 . 在每一个案例中，网站都是一团糟 . 更糟糕的是，它们通常充满了巨大的安全漏洞 .
我认为在很多情况下，转换为MVC比Webforms更容易 . 大多数经典ASP应用程序几乎没有关注点分离，因此最大的任务可能就是将数据访问，业务逻辑，业务实体和UI组件分离出来 . 在这样做时，可以更容易地将内联ASP代码转换为视图，将业务逻辑转换为控制器，将业务实体转换为模型 .
我不认为一个人比另一个更容易转换 .
如果你想在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时会有多好 .
还有更多ASP.NET-MVC比视图代码和ASP内联代码之间有明显的相似之处 . 要考虑的所有模型和控制器部件与大多数ASP的编写方式都有很大不同 .
那就是说我会说MVC将是最好的起点 .
IMO WebForms试图根据自己的喜好隐藏html，并且由于将大量html转换为webforms控件，可能会导致您的项目花费的时间超过您的预期 .
另一方面，MVC允许您重用一些逻辑，同时使您的应用程序更易于维护，并且使用适当的架构模式，您的应用程序可以比任何WebForms项目更快地开发和重构 .
我一直说MVC！
无论哪种方式，始终最好从头开始并仅实现逻辑 .
我很久以前就开始使用ASP（超过12年前），直到2006年我才转向ASP.NET 2.0，即使在今天我也不知道所有，但我确实知道我每天在工作中做的事情 .
在我看来，回顾我对ASP的了解，我会去Web Forms而不是MVC，首先，它是一种语言，它现在在“市场”中有些现在并且在全世界都很常用，而MVC仍然是在Beta中，因此，不适合 生产环境 环境（微软说 - 即使这个网站是用MVC编写的） .
我确实倾向于混淆MVC图表，如果我需要快速更改一个ASP项目，还有比我想要学习更多的技巧 .
这取决于 . ASP.NET MVC不是银弹，并且在许多方面在开发人员 生产环境 力方面向后退了几步 .
如果您的预算紧张并需要快速完成，我相信ASP.Net是可行的方式，因为它具有丰富的控件，如网格，分页，验证等，您可以立即使用 . 使用这些控件无疑会节省大量的开发时间 . 在ASP.NET中，所有这些最常被认为是行人的控件都必须从头开始创建，或者在使用ASP.NET MVC项目时从Internet获取 .
另一方面，如果您现在有时间和预算，并且希望有一个坚如磐石的解决方案，并且更容易适用于测试驱动开发，那么ASP.NET MVC可能是最佳选择 .
绝对ASP.NET MVC在风格方面更胜一筹 . （也就是说，您不必在WebForms应用程序中使用Repeater和其他愚蠢的控件，您可以像在MVC中一样使用内联代码 . ）
总的来说，MVC将是一个更容易的端口，为您提供更好的结构，并提供更愉快的体验 .
Web Forms更面向对象，而MVC就像.NET代码之上的经典ASP . 使用Web窗体或MVC，模型设计应该是相同的 . 唯一的区别是Web窗体具有面向对象的UI抽象，MVC使用函数和代码片段而不是类来组织UI代码 .
ASP.NET MVC优于Web Forms，用于UI的自动单元测试 . 但是，自动单元测试通常是不好的做法，对UI来说更糟糕 . 手动测试是构建高质量应用程序和充分利用开发时间的最佳方式 . 创建自动化单元测试是浪费时间，最终使用垃圾代码来维护核心代码 . 许多开发人员喜欢自动化单元测试，因为他们认为他们证明了他们的应用程序有效，这是错误的 . 他们还试图避免使用UML设计应用程序，因此他们使用测试驱动开发来设计使用负责设计不佳的应用程序的代码 . 使用TDD，您可以重构您编写的代码，而不必考虑使用模型的大局 .
所以MVC没用 . Web窗体使用更好的面向对象模型，而MVC更像旧式经典ASP和其他旧设计模式 . 这是2010年，MVC已经死了 . Web窗体就像用户界面的ORM .