"Design Pattern"可以应用于不同的程序吗?



我有2个程序A,B。如果 A 完成,我希望 B 知道这一点并开始运行,使用来自 A 结果的数据。

A 是一个 .NET Web 应用程序。我想这不会一直留在记忆中,对吧?只有在浏览器请求时才活着,对吧?

之前,A和B是同一程序的2个功能。但是B程序有时会由于业务原因而失败。即使B没有失败,也很耗时,并且会让客户等待太久而不满意。所以我把B分开了。客户顺利使用A,很高兴。B在后台做工作人员。

我目前的设计是:当A完成时,A将数据保存到数据库中。B 是一个 Windows 服务。它每 5 分钟检查一次数据库,如果找到新作业,则开始运行。A,B彼此不认识。

老板问为什么要闲置5分钟?我回答是因为这是实施我们某些业务的最简单方法。我没有设计太多。

所以我去看材料,发现Observer Pattern似乎是我想要的。经过几次阅读,我认为Observer Pattern只能应用于同一程序中的类,并且类和对象都在记忆中。

不确定我的问题是否是:GOF Design Patterns可以应用于不同的程序吗?

或者:像 RabbitMQ 这样的东西是如何实现这种实时处理类型的要求的?

我无法想象将 5 分钟的检查间隔设置为一个非常小的时间段。这对 CPU 来说是一个很大的负担。

编辑:我已经进入了关于ObserverPublish/Subscribe的解释,我认为这对那些从搜索中看到此线程的人很有用。

http://addyosmani.com/resources/essentialjsdesignpatterns/book/#observerpatternjavascript

观察者和发布/订阅模式之间的差异

观察者

模式要求希望接收主题通知的观察者(或对象)必须将此兴趣订阅到触发事件的对象(主题)。

但是,发布/订阅

模式使用主题/事件通道,该通道位于希望接收通知的对象(订阅者)和触发事件的对象(发布者)之间。此事件系统允许代码定义特定于应用程序的事件,这些事件可以传递包含订阅者所需值的自定义参数。这里的想法是避免订阅者和发布者之间的依赖关系。

这与观察者模式不同,因为它允许任何实现适当事件处理程序的订阅者注册并接收发布者广播的主题通知。

你说得对,观察者模式更适合设计 OO 类。 可以在程序之间工作的一种模式是发布-订阅模型,我认为这将非常适合您所描述的内容。 进程 B 订阅由 A 触发的某些事件。 这通常由服务体系结构调解;例如,进程 A 和 B 是 Web 应用程序(或 WCF/MVC/Web API),还有第三个应用程序调解发布-订阅模式。 因此,当 A 完成时,它会向发布-订阅服务发送一个事件;发布-订阅服务向该事件的所有订阅者(在您的情况下为应用程序 B)发送通知。

您可以自己实现此模式;也有 .NET 框架(如 NServiceBus)实现它。

使用"拉取模型"效率低下且浪费资源。发布-订阅模型是更好的选择。在此链接中,您可以看到将指导您的注释。这些示例是用Java编写的,但很容易实现.net。

应用程序之间观察者模式的类似机制是使用远程方法调用远程过程调用(因此在 Java 中调用)。在.Net中,它应该在:Windows Communication Framework下。

应用程序 A 通过 WCF 向应用程序 B 发送(异步)消息。应用程序 B 也可能首先将自己注册为消息收件人,但如果 A 不时崩溃,那将不是最好的选择。

最新更新