asp.net-mvc-3 - 将 WebForms 与现有的大型自定义控件库集成/切换到 MVC3

Question

这是情况。我们正在向基于 WebForms 的 webapps 套件添加一个新应用程序，所以我觉得这将是引入 MVC 的最佳时机。

我做了所有关于将两者混合的研究，并使用 Area 设置了所有项目。它使用 MVC 路由，而(visual studio)项目的其余部分以 Web 表单的方式运行。

母版页已转换为 Razor 布局，这还不错，因为每个应用程序之间只共享一个母版页。

我现在遇到的问题是重用用户控件。我们有几十个自定义用户控件，其中许多相当复杂，可以在我们所有的应用程序中重复使用。他们中的大多数(尤其是那些难以移植的)对 ViewState 和回发做了相当多的工作。

如果只是在 MVC 中重写这些，一次性成本会不太理想但并不可怕。但是由于现有的应用程序也需要维护和更新，使用完全不同的范式维护相同行为的 2 个版本似乎会极大地消耗生产力。

我的直觉说没有真正好的解决方案，我们可能不得不放弃为这个项目使用 MVC 的想法并坚持使用 webforms，但我想看看 SO 社区是否对在这种情况下该做什么有任何见解.

Answer 1

如果您有预算使用 MVC 范式重写这些服务器端控件，那将是最好的方法。如果没有，您仍然可以将它们嵌入到现有的经典 WebForms 页面中，这些页面将使用标准的 HTTP/HTML 技术与新的 MVC 应用程序进行通信:表单发布、通过查询字符串参数发送 id、iframe、cookie、HTML 5 存储等。 . 但有一件事是肯定的:尽量避免将这些服务器端控件放在您的 MVC View 中。您最终会得到一些既不是适当的 ASP.NET MVC 也不是适当的 WebForms 的混合应用程序，这将是一场灾难。

就我个人而言，我不得不多次进行相同的迁移，而且我没有费心在同一应用程序中使用区域或其他一些技术将经典的 WebForms 与 MVC 混合在一起。在一天结束时，试图让这两者同时存在可能会变成一场噩梦。它始终是两者之一:我有预算并且我正确地从头开始重写，或者我没有预算并且我使用 ASP.NET MVC 正确地做新的东西并尝试与现有的应用程序交互。

我发现简单地启动一个单独的 MVC 应用程序更容易，这取决于我正在寻找的交互将使用不同的方法来集成现有 WebForms 应用程序的功能。

我不太熟悉您的场景的复杂性和细节，因此很难提供客观的答案，但是继续基于现有的 WebForms 服务器端控件编写新代码并且根本不为此项目执行任何 MVC 的可能性可能也是一个很好的解决方案。仅仅为了它而在 ASP.NET MVC 上编写新应用程序可能并不总是最好的选择。