.net - WebBrowser 控件作为用户界面

Question

首先是一些定义，以保持清楚。

User: A live person, using the software

Client: A company that is paying for a customized version of our software for their users.

我们目前有一些应用程序需要根据用户所属的客户端对用户界面进行重大更改。我们目前为每个客户端单独构建，但随着客户端数量的增加，管理所有这些单独的版本变得越来越痛苦。
我的目标是切换到单个通用客户端，该客户端可以根据谁登录动态定制。由于我们的软件无论如何都需要互联网连接(广泛使用网络服务)，我正在考虑只在 .NET 中使用 WebBrowser 控件并允许它与计算机上所需的硬件交互(通过 ObjectForScripting)。
然后整个用户界面用 HTML/JavaScript 编写并存储在服务器上，从而使新用户界面的分发和维护变得轻而易举。通用客户端只不过是一个自定义 Web 浏览器，它知道如何与我们的硬件设备通信，并且可以通过 javascript 被告知这样做。
我看到这种方法有很多优点，但没有太多缺点。我错过了什么？为什么我不应该朝这个方向发展？

Answer 1

有一些商业应用程序成功地使用了这种方法。以下是一些需要牢记的注意事项。无论如何，这些都不应该阻止您尝试这种方法。不过，要问自己的一个关键问题是，该应用程序是否可以改为原生 Web 应用程序。

Web 浏览器控件“吃标签”。您可以使用 tab 键将输入焦点从宿主应用程序移到浏览器控件中，但您不能使用 tab 键离开它(除非您为此明确编码)

HTML/Javascript 应用程序是单线程的。如果您需要任何后台处理，您可能需要将该任务委派给托管应用程序。

如果错误情况发生在 Web 浏览器控件中，它们将被视为脚本错误，并包含在控件中。遏制是一件好事。但是您甚至可能没有意识到在构建/调试时发生了错误情况。

如果没有网络连接，用户会看到浏览器的故障页面。你不能抢占先机并展示你自己的信息。

根据您的应用程序及其实现方式，导航可能看起来比桌面应用程序中常见的更慢。特别是页面重新加载。谨慎使用异步 AJAX 可以帮助缓解部分或全部问题。

您的用户将知道他们正在使用网页。单靠 UI 设计将无法隐藏这一事实。响应能力和偶尔的失败将揭示这一事实。这对您来说可能是也可能不是问题。

您的应用程序必须支持多个浏览器版本。 .NET Web 浏览器控件是用户机器上 Internet Explorer 实现的包装器。那将是 IE6、7、8 等，具体取决于那里安装的内容。