【问题标题】:Windows Service Plus GUI/C#Windows 服务加 GUI/C#
【发布时间】:2009-12-21 21:19:14
【问题描述】:

我见过一些应用程序作为 Windows 服务运行,但仍可以提供一个 GUI,允许用户查看实际发生的情况。

例如,我们有一个构建报告的 Windows 服务。管理员希望查看许多统计信息,例如排队的报告数量、正在使用的内存量、平均构建时间等。

我们想做的是为管理员提供一种查看此信息的方式 - 例如可以连接到窗口服务以收集和显示此信息的应用程序......或者可能是应用程序本身可以使用的方式提供自己的 GUI 并在请求时显示它。现在,应用程序唯一会创建一个日志文件。

有没有办法做到这一点?

【问题讨论】:

    标签: c# windows-services


    【解决方案1】:

    几个。

    1. 有某种组件可以连接到您的 Windows 服务并通过远程处理将信息发送到另一个应用程序。如果你有一个 IoC 容器,那么巧妙地使用装饰器就可以做到这一点
    2. 使用服务总线、MSMQ、WCF、Growl 或类似的东西来广播有趣的信息。应用程序只需要知道如何挂钩。
    3. 公开 HTTP 端点或其他人可以连接到 Windows 服务并下载信息的东西
    4. 或者只是创建一个单页 WinForms 应用程序,它会不时读取日志文件并显示有趣的结果。

    (请注意,最后一个是迄今为止最简单的 - 提示提示,这样做。)

    【讨论】:

    • 谢谢 - 我设置了远程处理。它最终比选项 #4 容易得多......解析文本文件很糟糕:)
    【解决方案2】:

    理想情况下,服务与用户界面完全分离,原因有很多,我不会深入探讨。

    但是,您可以使用某种方式的 IPC 来查看此类信息。我的建议是使用 Remoting 从服务中请求所需的数据,然后根据需要将任何报告或图表构建到单独的应用程序中。

    【讨论】:

    • 我建议使用 WCF 而不是 Remoting。从设计的角度来看,Remoting 是紧密耦合的,可能会导致版本问题(限制对 WCF 服务的访问也比远程处理端点容易得多);从技术的角度来看,Remoting 是一项垂死的技术,已被 WCF 取代。
    【解决方案3】:

    不允许服务进行 UI API 调用(一种特定形式的消息框除外)。所以看起来有wser接口的服务实际上是两个进程。服务进程正在使用某种专有反向通道与标准 Windows APP 进行通信。可以是命名管道、套接字或一大块命名共享内存。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2010-12-18
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多