C# 发布到事件聚合器的每个小事件是否都需要是自己的空CompositePresentationEvent？

我试图从架构和设计的角度理解事件聚合器模式。我以前从未在WPF中使用过Prism，但我正在研究它如何在MSDN上工作

在我看来，对于每个事件，用户都必须创建一个新的事件对象来扩展

CompositePresentationEvent

。新事件对象似乎除了继承的功能外，没有其他功能（它本身通常没有代码）

例如：

addnewstuffent

看起来像：

public class AddNewStuffEvent : CompositePresentationEvent<Object> {} //The end of the class

对于

BookFlipEvent

：

public class HealthChangeEvent: CompositePresentationEvent<Object> {} //The end of the class

public class BookFlipEvent: CompositePresentationEvent<Object> {} //The end of the class

public class BookCloseEvent: CompositePresentationEvent<Object> {} //The end of the class

---

对于

BookOpenEvent

，

BookTearEvent

等的每一个小事件，这种情况都会永远持续下去。因此，在一个特定的命名空间文件夹中，将有大量的事件类，事件聚合器将在运行时加载所有这些事件对象。也就是说，每个小事件都需要一个空类？这就是它的工作原理吗？有什么更好的方法吗？

是的，每个事件类型都需要自己的类，您必须定义它

新事件对象似乎除了从中继承的功能外，没有其他功能

其目的只是为事件提供强类型。这使得编写代码订阅它们变得更容易。也就是说，订阅代码可以这样编写：

aggregator.GetEvent<AddNewStuffEvent>().Subscribe(Handler);

aggregator.GetEvent（）.Subscribe（处理程序）；

---

这是一种更好的替代方法，例如依赖于aggregator.GetEvent（“AddNewStuffEvent”）.Subscribe（Handler）（这在编译时无法验证。

@dbaseman是对的，但我也同意你的看法，这似乎有点尴尬。这不是因为你需要创建几十个小类——我一点也不介意——而是因为它使用类型作为名称，而不是真正的类型。为了实现强类型，它稍微弯曲了语言。仍然比另一个更好。谢谢。但是如果我打算使用此事件聚合器进行数据绑定，这不是很可怕吗？我可能会为每个属性更改事件创建一个类。哇！@xEnOn可能我遗漏了一些东西，但为什么需要这样做呢？

RaisePropertyChanged

仍然可以是一个事件，y每个属性不需要单独的类，对吗？我的工作中并没有使用WPF。我正在学习Prism中使用的架构设计，然后从中借鉴一些想法来创建我自己的。我的意图是首先创建一个事件聚合器，然后在这个事件聚合器的基础上，在我的基础上创建另一层数据绑定机制t、 因此，如果事件聚合器必须为每个事件都有一个单独的事件类，那么我关心的是，当我有许多属性更改事件时，它可能无法令人信服。@xEnOn啊，明白了。是的，为每个属性创建一个新类的想法显然是站不住脚的。