问题标签 [eventaggregator]

我对 CAL 和事件聚合器有一个有趣的问题。我正在尝试在应用停用或激活（application.activated 和 application.deactivated）时发布事件。我的一些模块有弹出框，当应用程序失去焦点时我想隐藏这些框。

这是下面的一个小代码示例

应用程序.xaml.cs

模块.cs

主持人

发生的情况是，当应用程序失去焦点时，我在控制台中得到以下内容 Deactivated - 在 app.xaml 当应用程序重新获得焦点时，我得到以下 App Deactivated - 模块

关于为什么事件聚合器会等到应用程序重新获得焦点以触发事件的任何想法。

谢谢

在Caliburn.Micro文档中，作者提到了这种可能性：

文档链接

IHandle 继承自标记接口 IHandle。这允许使用强制转换来确定对象实例是否订阅了任何事件。如果您与 IoC 容器集成，这将启用简单的自动订阅。大多数 IoC 容器（包括 SimpleContainer）都提供了一个钩子，用于在创建新实例时调用。只需连接容器的回调，检查正在创建的实例以查看它是否实现了 IHandle，如果是，则在事件聚合器上调用订阅。

如何使用 Autofac 实现这一目标？

我试图利用decorator的特性，但对于这种情况当然有点不合适。此外，默认情况下，我的IHandle<>实现者不会在容器中注册为IHandle的实例。

PS提供这个不正确的实现以防万一它可能有任何用处，尽管我怀疑。

我正在尝试使用 Unity 事件聚合器在应用程序的各个部分之间进行消息传递。目前，这是我想使用的 Prism 框架的唯一功能。我在理解我认为的基本概念时遇到了一些麻烦。

我的目标是在某些地方能够广播某个事件，然后在其他地方接收该事件。我发现这样做的代码需要访问 Unity 容器，据我所知，这需要在引导程序中进行配置，并且引导程序需要实例化窗口。在我只想使用事件聚合器的情况下，这似乎有很多额外的障碍。

有人可以为我指出正确的方向，以使用事件聚合器而不是 Prism 的其他代码吗？

自从了解了使用事件聚合器发布消息而不是使用事件之后，我已经设法处理了我的代码中的大多数事件（减去那些将 WPF 控件属性连接到我的代码的事件）。现在的问题是，我似乎真的用处理程序超载了我的服务。浏览 GitHub，我可以看到人们实现了事件聚合器（似乎采用了另一个名称，例如总线）并创建了一个类来处理每种类型的消息。

例如：

这种类型的编程使用什么术语？我想了解更多。

我在一个视图模型中有一个订阅方法，用于侦听另一个视图模型中的发布事件。出于某种原因，我无法弄清楚，当发布方法被触发时，订阅方法会运行多次（在我的情况下每次运行四次）。我在每个发布上都有断点，除了第一次发布调用之外，它们都没有触发。

调用堆栈不会随着订阅多个调用的发生而改变。

如何找出导致多次订阅调用发生的原因？

更新：当我找到它时，原来这是一个“doh”的答案。有问题的视图模型是表格/网格线的视图模型集合，自然，添加到网格的行越多，添加到事件聚合器的订阅越多。我需要实现一些取消订阅逻辑来摆脱那些我不想要的。

我正在努力编写一个测试，以确认我在 EventAggregator 关闭时正确取消订阅它。谁能指出（简单）答案？！

这是代码：

测试失败：

Moq.MockVerificationException：以下设置不匹配：IssuerSelectedEvent x => x.Unsubscribe(It.IsAny())

这是测试：

与 MVVM Light Messenger 服务相比，有人可以给我很好的概述 Prism EventAggregator 吗？具体来说;

• 它们是相似的东西，还是用于完全不同的目的？
• 两者的优缺点
• 应该和不应该使用它们的地方
• 在模块化开发中使用，例如与 MEF 或 Unity 结合使用时
• 您认为相关的其他信息

这是我没有看到太多解决的问题，当我的直觉告诉我应该使用其中一个时，我发现自己仍在同一个项目中使用这两种方法。

我正在使用 Prism 实现一个应用程序。该应用程序有一些分布式组件，它们驻留在各种机器或服务器上。为了与他们交流，我计划使用 Event Aggregator 实现消息传递服务。但在我开始研究之前，我想澄清一下：

1. 事件聚合器可以在分布式环境中使用吗？如果是，那么如何定义将发布或订阅消息的服务器或集线器？

2. 使用 Event Aggregator 对应用程序的性能有何影响？我觉得它可以忽略不计，但我仍然想知道。

3. 事件聚合器方法是否适合企业环境中的未来扩展？

谢谢并恭祝安康，

阿什·夏尔马

我正在寻找一个“最佳实践”（如果有最好的）来干净地关闭使用 MEF 和 PRISM4 的 WPF 应用程序。最终，我正在寻找某种“关闭服务”来管理从 Shell 到想要验证关闭应用程序是否可以的任何视图模型（或其他订阅者）的所有事件/命令。事件聚合器是最干净的方式吗？其他意见/选择？

理想情况下，我的 ToolbarRegion 中的 ToolbarView 上有一个按钮（我的 Shell 中的 2 个区域中的 1 个）。此按钮将调用我的 ToolbarViewModel 上的命令（引用我的 ToolbarControler 上的命令），这反过来会做两件事（我认为？）...首先，通知所有订阅者它的关闭时间并允许他们中的任何一个取消关闭并且...其次，如果没有取消，则以某种方式通知外壳程序关闭。我的应用程序的关闭模式设置为“ShutdownMode.OnMainWindowClose”，因此如果 Shell 关闭，我应该已准备就绪。

有人可以帮我解决这个问题吗？

我正在尝试为我的应用程序设计一个事件聚合器。（我是设计模式的新手，所以我可能还没有完全理解它）。

首先，我已经创建了一个解决方案，它在某种程度上是一个聚合器，但需要改进和重构以实现更高的效率并减少依赖关系。

1) 在事件聚合器设计模式中，我的 .NET 数据源是否会被视为发布者？（我不确定出版商的角色是）。

2) 我将如何设计我的解决方案来处理不仅对特定数据源的订阅，而且还能处理特定数据事件而忽略其他事件？我希望看到一种解决方案，它可以摆脱保留列表并不知疲倦地循环遍历它们……但不确定我是否可以一起避免这种情况。