关于asp.net:.NET Web应用程序到SilverLight的可移植性

关于asp.net:.NET Web应用程序到SilverLight的可移植性

.NET Web Application Portability to SilverLight

我工作的公司创建了该应用程序,该应用程序是我们业务的核心,并依靠Web浏览器来执行某些"规则",如果没有这些规则,则该应用程序对我们的客户来说就毫无用处。很抱歉,必须谨慎行事,NDA和许多其他事情使我无法确切地说出应用程序是什么。本质上,JavaScript控制某些定时事件(至少必须精确到至少第二个事件),这些事件很难用ajax / postbacks等控制。

我的问题是:假设大多数代码实际上是C#业务逻辑而不是asp.net控件,那么将ASP.NET应用程序转换为SilverLight有多困难?我刚听完Deep Fried字节,MS员工听起来好像没什么大不了的。这对于Web应用程序(或主要是Win32应用程序)是否适用?

我知道asp.net前端与SilverLight根本不同,但是有很多C#代码我不想在必要时不必重写。我假设将javascript代码替换为silverlight是微不足道的(我知道错误的假设,但是我必须从某个地方开始),因为它处理定时事件,因此我对此并不真正担心。我需要提出一种解决方案,以减轻这种问题,我希望这是一个中间立场:不采取任何措施,并看着我们受到客户的追捧,并以比网页更安全的方式重写整个应用程序仅前端验证。有没有人试图将ASP.NET代码转换为SilverLight项目?


如果您的应用程序大部分位于后端,则您仍应能够保持大部分代码不变,而仅替换前端。但是,Silverlight需要了解WPF,这与您的应用程序当前使用的HTML / JS截然不同。我想说的是,如果您的UI很薄,则应该很容易移植到Silverlight,但是UI中的业务逻辑越多,难度就越大。


将代码从ASP.NET移植到Silverlight并非易事。正如Nate指出的,这取决于ASP.NET应用程序中有多少基于AJAX,以及有多少基于服务器控件。

Silverlight是一种状态完整的客户端技术,这意味着一切都在浏览器内部的客户端上运行。 ASP.NET是一种服务器技术,它围绕请求/响应模型构建。由于这两个是完全不同的范例,所以这不是直截了当的。

但是,由于ASP.NET只是表单数据的HTML和HTTP POST,因此人们进行了实验,他们直接在ASP.NET页的顶部添加了Silverlight应用程序,并手动发送了确切的数据来手动构建HTTP POST请求ASP.NET应用程序的工作。这几乎就像为您自己的应用程序进行"屏幕抓取"。这可能有效,但不是最佳选择。您的ASP.NET应用程序将不得不针对每个请求经历整个页面周期,因此不会提高性能。

更好的替代方法是开始将用户在APS.NET应用程序中具有的所有功能包装为Web服务。您可以在ASPX页面旁边添加这些服务,然后逐步移植应用程序。您将基于这些服务从头开始构建的UI。

祝好运!


您使用了多少类库以及可能被视为"危险"的东西,例如pinvoke,文件系统访问和System.Diagnostics.Process?


推荐阅读