我有一些想法,为了降低发布和订阅事件的复杂性,Eventaggregator 充当单一来源。这方面还有什么可以理解的。我只想要一个一般性的描述,而不是通过代码的例子。
2 回答
的想法EventAggregator
是您不需要知道引发事件的源对象。通常要订阅/收听事件,您必须将源对象带到您的班级,然后像这样订阅事件:
// Object will raise event
public class EventSourceClass
{
public event EventHandler<EventArgs> OnMyEvent;
}
现在 - 想要订阅事件的类/对象必须以某种方式知道这样的EventSourceClass
类:
// Object will listen to events from very specific (EventSourceClass) class
public class EventListenerClass
{
...
EventSourceClass eventSourceClass = new EventSourceClass(....);
eventSourceClass.OnMyEvent += ......
...
}
EventAggregator
简单点:
- 您定义描述事件的类(类继承自
CompositePresentationEvent<>
. - 然后在事件引发者课程中,您就
EventAggregator.GetEvent<event-type>().Publish(build-your-event-here)
在准备引发事件时。 在事件侦听器类中,您只需关注
EventAggregator.GetEvent<event-type>().Subscribe(function-that-will-start-to-work)
此事件。它被称为将源对象与侦听器解耦,因为引发事件的类和事件侦听器类都不必相互了解——它们都应该只知道
EventAggregator
——最终的事件传递/事件总线对象。如果您发现此信息对您有用,请告诉我。
从 EventAggregator MSDN 页面的第一行开始:
EventAggregator 服务主要是一个事件容器,允许发布者和订阅者解耦,以便它们可以独立发展。这种解耦在模块化应用程序中很有用,因为可以添加新模块来响应 shell 或更可能是其他模块定义的事件。
阅读该页面的其余部分以了解更多关于它的工作原理以及如何使用它的示例。我喜欢遵循的一般规则是,对于 Model->ViewModel 通信,标准 .NET 事件是好的,但对于 ViewModel->ViewModel(或 Module->Module)通信(两者都不应该真正“了解”彼此), EventAggregator 很好。