【问题标题】:Silverlight as front-end for business applicationSilverlight 作为业务应用程序的前端
【发布时间】:2009-12-02 23:44:45
【问题描述】:

我们正在开发一个新的基于 .NET 的商业应用程序,该应用程序将在 Windows 服务器(可选 Azure)上作为服务运行后端。 为此,我们正在考虑使用 Silverlight 作为唯一 前端/GUI 来访问应用程序 - 主要是因为这将允许从各种客户端操作系统平台轻松访问。 应用程序的用户(获得许可的公司)将自己运行后端服务——我们不会将其作为服务出售——它将是一个“老式”的收缩包装应用程序。

您是否认为 Silverlight 已经足够成熟了?

您知道现有的任何类似这样工作的商业应用程序吗?

有什么具体的建议/要注意实现这样的事情吗?

【问题讨论】:

  • 真的很接近主观,需要讨论...

标签: .net silverlight


【解决方案1】:

是的,Silverlight 已经足够成熟了。

我于 2008 年 7 月开始使用它进行开发,并在八个月后发布了可部署的客户端/服务器农业遥测监控系统的第一个版本。尽管有一些小问题和不发达的领域(2.0 比 3.0 更多),但我发现它在开发快速、交互式客户端 UI 方面比 Windows 窗体好得多——甚至没有让我开始与通常的 www 技术进行比较。 ..

我强烈推荐它,尤其是结合 WCF 数据服务或 RIA 服务用于商业应用程序。

【讨论】:

    【解决方案2】:

    我使用 Silverlight 作为医疗行业商业应用程序的前端。没有严重的陷阱,只要确保您生成线程来处理耗时的工作,这样 UI 就不会冻结在您身上,并确保在您访问 Web 服务时准备好 clientaccesspolicy.xml 文件。

    Silverlight 3 中解决的两个“业务”问题是缺乏错误处理(半解决)和对基于消息的安全性的支持。解决这些问题对于 Silverlight 试图将自己推销为一种业务就绪技术有很大帮助。我的意见是已经足够了。

    对于 SL2,有两个限制阻止了错误处理。首先,服务器异常以响应代码 500 的形式出现,浏览器插件无法处理。其次,SL2 中没有异常支持。 SL3 通过添加 ExceptionDetail 和 FaultException 类解决了第二个问题。第一个问题仍然存在。响应代码 500 会阻止 silverlight 访问响应的内容,但作为一种解决方法,您可以发回 200 而不是 500 的响应代码。

    SL2 仅支持基于浏览器的安全性。使用该安全模型开发的应用程序可能容易受到可访问缓存浏览器凭据的恶意应用程序的跨域伪造尝试。基于消息的安全性通过在每条消息中包含凭据来解决该问题。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2011-04-29
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多