从 WebForms 与现有的大型自定义控件库集成/切换到 MVC3
情况是这样的。我们正在向基于 WebForms 的 Web 应用程序套件添加一个新应用程序，因此我认为这将是引入 MVC 的最佳时机。
我做了有关将两者混合的所有研究，并使用使用 MVC 路由的 Area 来设置项目，而 (Visual Studio) 项目的其余部分按照其运行方式使用 Web 表单运行。
母版页被转换为 Razor 布局，这还不错，因为每个应用程序之间只有一个共享母版页。
我现在遇到的问题是重用用户控件。我们有数十个自定义用户控件，其中许多相当复杂，在我们的所有应用程序中重复使用。他们中的大多数（尤其是那些难以移植的）在 ViewState 和回发方面做了相当多的工作。
如果只是在 MVC 中重写这些内容，一次性成本虽然不太理想，但也不算太糟糕。但由于现有的应用程序也需要维护和更新，因此使用完全不同的范例维护相同行为的两个版本似乎会极大地消耗生产力。
我的直觉告诉我，实际上并没有一个好的解决方案，我们可能不得不放弃在这个项目中采用 MVC 的想法，而坚持使用 Web 表单，但我想看看 SO 社区是否对在这种情况下该怎么做有任何见解。
Here's the situation. We're adding a new application to our suite of webapps based on WebForms and so I felt this would be the perfect time to introduce MVC.
I did all the research about intermingling the two and got the project all set up using an Area that uses MVC routes while the rest of the (visual studio) project runs with web forms the way it's been running.
Master pages were converted to Razor layouts, not too bad because there was only one master page that was shared between every application.
The problem I've run into now is reusing user controls. We have dozens of custom user controls, many of them fairly complex, that are reused throughout all of our applications. Most of them (especially ones that would be difficult to port) do a fair amount with ViewState and postbacks.
If it were just a matter of rewriting these in MVC, the one time cost would be less than ideal but not terrible. But since the existing apps need to be maintained and updated as well, it seems like maintaining 2 versions of the same behaviour using entirely different paradigms would be a huge drain on productivity.
My gut says there isn't really a good solution and we may have to abandon the idea of going to MVC for this project and stick with webforms, but I wanted to see if the SO community has any insight on what to do in this scenario.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您有预算使用 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 上编写新应用程序可能并不总是最好的选择。
If you have the budget to rewrite those server side controls using the MVC paradigm that would be the best way to go. If not, you could still embed them into existing classic WebForms pages and which would communicate with the new MVC application using standard HTTP/HTML techniques: form posts, sending ids through query string parameters, iframes, cookies, HTML 5 storages, etc... One thing's for sure though: try to avoid putting those server side controls in your MVC views. You will end up with some hybrid application that is neither proper ASP.NET MVC nor a proper WebForms which would be a disaster.
Personally I had to do this same migration multiple times and I didn't bother mixing classic WebForms with MVC in the same application using Areas or some other techniques. At the end of the day it might turn into a nightmare trying to make those two exist together. It's always one of the two: I have the budget and I rewrite from scratch properly or I don't have the budget and I do the new stuff properly using ASP.NET MVC and try to interact with the existing application.
I find it easier to simply start a separate MVC application which depending on the interaction I am looking for would use different methods for integrating functionality from the existing WebForms application.
I am not quite familiar with the complexity and details of your scenario so it is difficult to provide an objective answer but the possibility of continuing to write new code based on the existing WebForms server side controls and not doing any MVC at all for this project might also be a good solution. Writing a new application on ASP.NET MVC just for the sake of it might not always be the best choice.