asp.net-mvc-3 – 将WebForms中的MVC3与大型现有的自定义控件库

发布时间：2020-12-16 10:00:49 所属栏目：asp.Net 来源：网络整理

导读：这是情况.我们正在为基于WebForms的webapps套件添加一个新的应用程序,所以我觉得这将是引入MVC的最佳时机. 我完成了关于混合两者的所有研究,并使用使用MVC路线的区域进行了所有项目的建立,而(视觉工作室)项目的其余部分以其运行的方式运行. 母版页被转换为Ra

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

我完成了关于混合两者的所有研究,并使用使用MVC路线的区域进行了所有项目的建立,而(视觉工作室)项目的其余部分以其运行的方式运行.

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

我现在遇到的问题是重用用户控件.我们有许多自定义用户控件,其中许多都相当复杂,可以在我们的所有应用程序中重复使用.其中大多数(特别是那些难以移植的东西)使用ViewState和回发做了相当多的事情.

如果只是在MVC中重写这些内容,那么一次性成本将不太理想,但并不可怕.但是由于现有的应用程序也需要维护和更新,似乎使用完全不同的范例维护相同行为的2个版本会大大降低生产力.

我的直觉说没有一个很好的解决方案,我们可能不得不放弃为这个项目转到MVC并坚持使用webforms的想法,但我想看看SO社区是否对这个场景中的操作有任何见解.

解决方法

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

我个人不得不多次进行同样的迁移,并且我没有在使用区域或其他技术的同一应用程序中混淆经典的WebForms和MVC.在一天结束时,它可能会变成一场噩梦,试图让这两者一起存在.它总是两个中的一个：我有预算,我从头开始正确重写,或者我没有预算,我使用ASP.NET MVC正确地完成新的东西,并尝试与现有的应用程序进行交互.

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

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!