我的公司已经开发(并且仍在继续开发)一个大型 ASP.NET 业务应用程序。我们的平台是使用一些 ASP.NET Ajax 的 ASP.NET 2.0。我们广泛使用第三方组件,例如 webgrids、comboboxes、treeviews、日历和调度控件等。
现在,我不太了解 ASP.NET MVC,我想知道是否有办法在 ASP.NET MVC 模型中使用这些第三方控件。或者供应商是否必须重写他们的产品才能使它们适合 ASP.NET MVC?
我的公司已经开发(并且仍在继续开发)一个大型 ASP.NET 业务应用程序。我们的平台是使用一些 ASP.NET Ajax 的 ASP.NET 2.0。我们广泛使用第三方组件,例如 webgrids、comboboxes、treeviews、日历和调度控件等。
现在,我不太了解 ASP.NET MVC,我想知道是否有办法在 ASP.NET MVC 模型中使用这些第三方控件。或者供应商是否必须重写他们的产品才能使它们适合 ASP.NET MVC?
如果他们使用 ASP.NET 控件模型(这将是 ASP.NET 控件供应商编写的大约 99.9% 的控件),他们必须重写他们的控件。其中有多少工作,取决于他们的控件的架构而有很大的不同——他们已经使用的 ajax 越多,他们就越容易将其更改为 MVC。
用于示例的 ASP.NET AJAX 控件工具包可以与 MVC 一起使用。您可以在 WWW.ASP.NET 上的视频中看到如何做到这一点:http ://www.asp.net/learn/mvc-videos/video-373.aspx
许多控件需要重写,因为它们中的大多数都需要经典 ic webforms 中的回发模型。并且在 asp.net mvc 中没有回发。
所以:组件需要回发吗?-> 不能在 asp.net mvc 中工作
作为记录。我收到了 Telerik 电子邮件通讯,其中包含一些有趣的消息:
“我们最令人兴奋的产品创新之一是 RadControls for ASP.NET AJAX 能够在新的 Microsoft ASP.NET MVC 框架中工作。” [...]
ISV 市场肯定在追赶 MVC,但这是有道理的——它还不是 RTM(尽管最后一个预览版至少有明确的“上线”许可证)。常规的 Webforms 控件几乎需要重写。
我不认为主要参与者需要很长时间才能赶上,但是如果您使用的是较小公司的产品,则可能很难将其优先考虑 MVC。一个(非常hacky)选项可能是使用IFRAME 或AJAX 将页面的一部分视为单独的aspx 页面......真的,真的很讨厌。
当市场份额如此之低时,您必须质疑第 3 方市场对创建 mvc 控件的兴趣。他们似乎只想专注于 webforms 和 silverlight/wpf 控件。
我正在审查 mvc 的同步融合工具(刚刚下载)。值得一看。似乎实际上是为 MVC 设计的。