事件驱动架构......无限循环

Question

我有一个事件驱动的架构,其中A等待B的变化,B等待C的变化,C等待A的变化,形成一个循环.

现在,如果B发生变化,那么A会向C发射一个事件,该事件将激活到B,然后激活到A,激活到C ...无限制.

我现在可以改变我的程序,不包含这个循环,但我担心我可能会把自己放在一个角落,以后我不能.在设计基于事件的系统时,如何防止这些事情发生？

Answer 1

这里的每个人似乎都说循环依赖是不好的。这在某种意义上是正确的，我试图不惜一切代价避免静态循环依赖。您可以使用此博客中概述的控制反转来做到这一点：http : //blog.schauderhaft.de/2011/07/17/break-dependency-cylces/

但是你所描述的不一定是静态循环依赖，而是运行时的依赖。我不完全确定，但我认为在运行时避免循环依赖或多或少是不可能的。但是当然这不应该导致无限循环。为了解决这些问题，我看到了两个半选项

首先是黑客

确保由另一个事件触发的每个事件都有对原始事件的引用（或有关它的基本信息，如 id）。当你处理一个事件时，确保它不是来自你自己。

优点：易于实施；绝对防止递归

黑客的另一半

如果您正在运行同步，您可以firingEvent在之前设置一个标志并在之后重置它。忽略进入 whilefiringEvent设置的事件。

优点：更容易实现；在单线程中运行时绝对防止递归

语义丰富的解决方案

我确信 A 在某个外部触发器上触发的事件和 A 因为 C 触发而触发的事件实际上是两个不同的事件，或者所有三个事件实际上只是一个可能来自尚未确定的源 D 的事件。或者类似的东西。如果没有信息，就无法知道 A、B 和 C 是什么以及它们正在触发什么事件。如果您找到合适的事件，循环就会消失。

优点：设计将更简洁并包含更多信息。

Answer 2

循环依赖确实很糟糕。我必须先从 A、B 和 C 的角度写下你的帖子，然后才对我有意义。我认为你应该摆脱它。如果您将自己置于困境，这可能比循环依赖可能遇到的问题要好得多。

您也绝对可以避免这种情况。A、B 和 C 确实紧密耦合。我认为你需要重新考虑他们的责任。也许有一个常见的 D 元素可以减轻您的设计压力。

我想到的其他东西是架构分层。如果您可以将 A 分层放在 B 上，并要求与 B 交谈的任何人进行通信以穿过 A 并向下分层，那么您可能会更轻松。再说一次，我对你的问题不太了解，所以这些只是广泛的建议。

最后一个选择，也是我最不喜欢的，是在三个组件之间传递消息。当访问每个组件时，要求每个组件将其已看到该消息添加到消息中。然后，下一个获取消息的组件将包含有关谁看到该消息的信息。有点像登记表。但同样，最不喜欢的。先尝试别的事情。

祝你好运！