从ASP.NET WebForms迁移到MVC

Question

我看过很多关于从ASP.NET Webforms转换到MVC几乎是不可能的问题和文章。然而，我认为我的情况是不同的。

大约一年前，我在Webforms上开始了一个项目，但我采取的方法（就我所知）非常像MVC。我禁用了表单验证，不使用任何回发，使用URL重写，所有页面更改都是AJAX请求，加载ContentPlaceHolders的页面内容（使用小技巧，覆盖RenderControl方法）。我还在网站中引用了自己的ORM和RESTful Service API的分离项目。

现在系统运行得非常好，页面部分刷新正常，并且在进行ajax调用时URL会发生改变，因此当刷新页面时，它看起来完全相同。

现在我刚刚被告知需要为一个新的大型项目学习MVC（但我必须先完成另一个项目），但是我已经阅读了一些相关主题并启动了一些Hello World应用程序，似乎ASP.NET MVC的理念与我已经创建的内容非常相似。

那么StackOverflow仍然推荐不要将Webforms应用程序转换为MVC吗？除了最佳实践之外，是否有转换到MVC的其他好处？

- Connell

---

你当然可以将WebForms转换为MVC，但这个过程将涉及大量的复制/粘贴/重写。 - jrummell

在我看来，“除了最佳实践之外，转换为MVC是否还有其他好处？”这个问题与本题的其余部分是两回事。 - Jeffrey Blake

如果它本来就很好用，就不要重写它。 - Erix

@Erix - 很多“有经验”的程序员使用这个概念，但我坚信这是错误的态度。如果我编写了一些烂代码，能够为快速完成任务提供帮助，随后代码扩展并可能由我或其他开发人员继续开发，如果我按照特定的标准重新编写该代码，将会节省我很多时间和金钱。 - Connell

Answer 1

我有一个非常大且古老的ASP.NET WebForms应用程序（最初是为.NET 1.1编写的！），并启用了MVC以使其并行运行。我一直在使用MVC编写新功能，将旧的WebForms功能转换为MVC控制器和视图。

我遇到了一些有关URL授权和在IIS集成模式下运行的小问题，但一旦我理解了这些问题，它们就很容易解决。所以几乎不可能？当然不是！

我无法告诉您是否值得转换，因为我不知道您的应用程序的大小，范围或性质，也不知道任何业务限制。然而，转向MVC对于开发和质量的方便性都是相当大的改进（因为更容易进行分区和单元测试）。更不用说，我在MVC中编写（或重写）的功能比WebForms等效功能更加清晰、更快速和响应更好。

我很兴奋将其从MVC v2升级到v3，并转换为Razor视图。如果我是您且有时间的话，我会这么做。

以下是我发布的一个问题，概述了转换过程和我遇到的一个较大的问题：将传统的ASP.NET迁移到MVC 2（RC）：HttpApplication事件未触发，用户主体为空

- moribvndvs

---

这个项目是一个相当大的网络，是我职业生涯中最大的学习曲线。我在工作中学到的一切，都回家去实现或者重新设计这个项目以使其更好。时间不是问题，因为没有截止日期，我也没有得到报酬。有一件事情（终于！）似乎对我有益处，那就是我喜欢重写轮子——所以我使用自己的ORM（这将是模型？），UserControls（视图和控制器？），登录/注册框架，RESTful API框架。 - Connell

我觉得你会喜欢使用MVC框架开发，这真的很有意思。我从一开始就不喜欢WebForms（但是我喜欢ASP.NET的架构），我理解你不想重复制造轮子的感受。 - moribvndvs

Answer 2

我最近将一个中等规模的WebForms项目转换为MVC。我不会建议初学者在第一个MVC项目上进行此操作，但一旦你掌握了它，你就可以逐步将WebForms应用程序转换为MVC。

我注意到其中一个主要好处是“速度”。通过放弃视图状态、数据绑定和Web控件的怪癖，你将得到一个更快的应用程序。

当然，还有更为人所知的好处，如可测试性和对生成的HTML的完全控制。

WebForms和MVC共享相同的基本ASP.NET平台，因此它们并不像你读到的那样不兼容。

- Marnix van Valen

---

完全控制生成的HTML将是很好的。我已经厌倦了在我的用户控件中输入override string ClientID { get { return ID; } }！ - Connell