【发布时间】：2016-08-21 13:35:47
【问题描述】：
我目前正在为我们的组织研究一组应用程序的重新架构。我们目前有一组 10-15 多个独立应用程序，它们相互通信并提供客户端软件和硬件之间的中间层。
当前模型的问题是大量单独的应用程序，它们增加了内存开销、通信延迟、系统膨胀，并且在这些应用程序中的任何一个崩溃时难以从问题中恢复。
我正在考虑将应用程序组合成 1-2 个逻辑单元，以帮助解决其中的一些问题。困境在于如何做好这件事：
- Windows 服务
- UI 应用程序
- 两者都有？
我们的目标是拥有一个始终在线的系统，该系统将处理所有客户端硬件通信，同时拥有丰富的管理员用户配置 UI，能够与该系统的所有单独组件通信并提供配置/etc 能力。拥有 WinForms/WPF 应用程序将允许管理员用户轻松访问系统配置并提供实时反馈（相机馈送等），但会让管理员不小心关闭窗口。让服务完成所有这些工作很棒，但我不确定如何提供丰富的管理员用户 UI 来交互和更改此服务。
有什么值得一读的想法或链接吗？
谢谢！
【问题讨论】：
-
这可能不适合回答这个问题。在这里试试：programmers.stackexchange.com
-
是什么阻止了您同时拥有客户端应用程序和 Windows 服务，甚至是系统托盘应用程序？
-
你在正确的轨道上，如果你需要一个始终在线的服务来监控硬件通信，你需要一个 Windows 服务。然后，您可以将 WPF 应用程序作为 UI，它可以与您的服务对话，或与共享的本地数据库对话。您可以使用 RPC 从您的 WPF 应用程序与您的 Windows 服务对话，或者使用 SQL 数据库可能更好。因此，您的服务可以将数据写入数据库，而您的 UI 可以将其读出。另一种选择是让 UI 通过 TCP 套接字连接到您的服务，并以这种方式发送/接收消息。
-
我打算按照@Mangist 的思路提出一些建议。我们有一个通过 WCF 与 Windows 服务通信的 MVC 应用程序。您有很多选择。
-
@roryap 在引用其他网站时，指出cross-posting is frowned upon 通常会有所帮助
标签： c# wpf winforms service architecture