C#:应用程序之间的解耦通信

时间:2009-11-06 13:09:14

标签: c#

我被要求编写一个应用程序,它将作为许多其他外部应用程序的控制器。它将作为计划任务运行,其目的是处理它在特定位置找到的任何新文件,并根据文件类型调用外部处理程序来处理它们。

控制器应用程序必须等到处理程序应用程序完成后再调用next,并且还需要知道它是否成功。

还有一个复杂的问题,即某些文件可能是软件包,软件包的目的可能是更新控制器应用程序本身。因此,我使用的任何框架都必须考虑到这一点。

基本上我只是想在这里寻找一些设计灵感来尝试找出控制器和处理程序之间解耦通信的强大方法。

3 个答案:

答案 0 :(得分:2)

我认为你有两个完全不同的问题:

  1. 控制器/处理程序通信
  2. 控制器的就地软件更新
  3. 如果您能够更详细地描述这些处理程序的外观,将会很有帮助。它们是具有实现处理程序接口的类的.NET程序集吗?如果是这样,那么我几乎建议使用MEF来定位和加载处理程序并执行它们。 MEF可能使这些处理程序的位置和加载更容易。

    自我更新应用程序总是有些棘手。我解决这个问题的一种方法是拥有一个由两部分组成的应用程序。第一部分是一个小型的bootstrapper应用程序,它只知道如何启动控制器。从本质上讲,定位控制器应用程序并启动它是引导程序的工作。我这样做的方法是拥有一个目录,其中包含我已部署的每个新版本应用程序的一个子目录。引导程序只选择最高版本并启动它在该目录中找到的控制器应用程序。

    示例控制器目录结构:

    \Programs
        \Controller
            bootstrapper.exe
            \v1.0
                controller.exe
            \v1.1  <-- Current version
                controller.exe
    

    当应用更新时,所有发生的事情都是在控制器目录中创建一个新的“version”目录,并且更新会向控制器返回一个代码,指定需要重新启动。一旦控制器完成它的工作,它就会退出。由于整个过程由引导程序启动(并且引导程序在启动控制器时阻塞),因此引导程序在控制器启动时重新获得控制权。引导程序只是再次执行它的启动过程,找到新的控制器版本,然后启动它。

    这里的一个问题是更新引导程序并不容易,但通常这不会经常更新,因为它只包含非常少的代码。

    希望有助于或激发一些想法。

答案 1 :(得分:0)

您可以尝试使用NServiceBus作为控制器和处理程序之间的消息传递系统。听起来这是一个非常简单的场景,控制器向特定处理程序发送消息然后等待响应。根据响应,它将另一个消息发送给另一个处理程序,依此类推。

不知道如何进行远程更新。

答案 2 :(得分:0)

你可以这样思考: 作为Windows服务托管的WCF服务中的工作流。您可以根据您的要求决定是否需要顺序或状态工作流程。我希望this能帮助您更好地理解