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

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

我做了所有关于将两者混合的研究，并使用一个使用MVC路由的

区域来设置项目，而剩下的（visual studio）项目以web表单的方式运行

母版页被转换为Razor布局，这并不太糟糕，因为每个应用程序之间只有一个共享的母版页

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

如果只是在MVC中重写这些代码的问题，那么一次性成本将不太理想，但也不可怕。但由于现有的应用程序也需要维护和更新，因此使用完全不同的模式维护相同行为的两个版本似乎会极大地消耗生产率

我的直觉告诉我没有一个好的解决方案，我们可能不得不放弃这个项目去MVC的想法，坚持使用webforms，但是我想看看SO社区是否对在这种情况下该做什么有什么见解。
如果您有预算使用MVC范式重写这些服务器端控件，这将是最好的方法。如果没有，您仍然可以将它们嵌入现有的经典WebForms页面，并使用标准HTTP/HTML技术与新的MVC应用程序进行通信：表单帖子、通过查询字符串参数发送ID、iFrame、cookie、HTML5存储等等。。。但有一件事是肯定的：尽量避免将那些服务器端控件放在MVC视图中。您将得到一些既不是正确的ASP.NET MVC也不是正确的WebForms的混合应用程序，这将是一场灾难

就我个人而言，我必须多次进行相同的迁移，而且我没有在同一个应用程序中使用区域或其他技术将经典WebForms与MVC混合使用。在一天结束时，试图让这两个人同时存在可能会变成一场噩梦。这总是两种情况中的一种：我有预算，我从头开始正确地重写，或者我没有预算，我使用ASP.NET MVC正确地完成新工作，并尝试与现有应用程序交互

我发现简单地启动一个单独的MVC应用程序更容易，它根据我所寻找的交互使用不同的方法来集成现有WebForms应用程序的功能

我不太熟悉您的场景的复杂性和细节，因此很难提供客观的答案，但继续基于现有WebForms服务器端控件编写新代码，并且完全不为该项目执行任何MVC的可能性也可能是一个很好的解决方案。在ASP.NET MVC上编写一个新的应用程序可能并不总是最好的选择
 +1如果你没有重写的预算，还有一种可能从MVC中获得一些好处。您可以将MVC用作API。例如，如果使用具有丰富客户端API的控件（例如，Telerik的ASP.NET AJAX控件），则可以使用从其方法返回json的控制器执行客户端数据绑定等操作。我过去使用过这种方法，它允许更好地对代码进行单元测试，使提供可下载的导出数据变得更容易，等等。