这是情况。我们正在为我们的基于 WebForms 的 webapps 套件添加一个新应用程序，所以我觉得这将是引入 MVC 的最佳时机。
我做了所有关于将两者混合的研究，并使用一个使用 MVC 路由的项目设置了所有项目Area，而（Visual Studio）项目的其余部分以 Web 表单的运行方式运行。
母版页被转换为 Razor 布局，这还不错，因为每个应用程序之间只有一个母版页共享。
我现在遇到的问题是重用用户控件。我们有几十个自定义用户控件，其中许多相当复杂，可在我们所有的应用程序中重复使用。他们中的大多数（尤其是那些难以移植的）在 ViewState 和回发方面做了相当多的工作。
如果只是在 MVC 中重写这些，一次性成本将不太理想但并不可怕。但是由于现有的应用程序也需要维护和更新，因此使用完全不同的范例维护相同行为的 2 个版本似乎会极大地消耗生产力。
我的直觉说没有真正好的解决方案，我们可能不得不放弃为这个项目使用 MVC 并坚持使用 webforms 的想法，但我想看看 SO 社区是否对在这种情况下做什么有任何见解.
如果您有预算使用 MVC 范例重写这些服务器端控件，那将是最好的方法。如果没有，您仍然可以将它们嵌入到现有的经典 WebForms 页面中，并使用标准 HTTP/HTML 技术与新的 MVC 应用程序进行通信：表单帖子、通过查询字符串参数发送 id、iframe、cookie、HTML 5 存储等。 . 有一件事是肯定的：尽量避免将这些服务器端控件放在您的 MVC 视图中。您最终会得到一些既不是正确的 ASP.NET MVC 也不是正确的 WebForms 的混合应用程序，这将是一场灾难。
就我个人而言，我不得不多次执行相同的迁移，并且我没有费心在同一个应用程序中使用 Areas 或其他一些技术将经典 WebForms 与 MVC 混合。归根结底，试图让这两者同时存在可能会变成一场噩梦。它总是两者之一：我有预算并且我从头开始正确地重写，或者我没有预算并且我使用 ASP.NET MVC 正确地做新的东西并尝试与现有的应用程序交互。
我发现简单地启动一个单独的 MVC 应用程序更容易，这取决于我正在寻找的交互将使用不同的方法来集成现有 WebForms 应用程序的功能。
我不太熟悉您的场景的复杂性和细节，因此很难提供客观的答案，但有可能继续基于现有的 WebForms 服务器端控件编写新代码并且根本不为该项目执行任何 MVC 可能也是一个很好的解决方案。仅仅为了它而在 ASP.NET MVC 上编写一个新应用程序可能并不总是最好的选择。