我不确定WPF MVVM应用程序中的模型类之间进行通信的一种好/正确方法。现在，我的模型类使用事件聚合器（具体来说是Caliburn.Micro）与其他模型类进行通信。
我不确定这是否被视为反模式，但感觉不正确（请参见下面的注释）。我喜欢事件聚合器提供的松散耦合，但是我可以想象到抽象使得代码可能更难以阅读。但是话又说回来，这似乎也是抽象的结果。
注意：目前，同一事件聚合器正在用于模型->模型类通信和视图模型<->模型类通信。我可以看到这不是理想的，如果我的问题的答案是肯定的，我可以轻松地创建一个单独的事件聚合器，专门用于模型<->模型类通信。
我了解事件聚合器的作用，特别是对于视图模型<->视图模型通信和视图模型<->模型通信。但是，正在讨论的应用程序具有相当复杂的模型，我不确定使用事件聚合器是否适合进行模型<->模型通信。
在WPF MVVM应用程序中使用事件聚合器在模型类之间进行通信是否可以接受？
如果是，我应该在我的应用程序中使用2个事件聚合器吗？
如果没有，您会建议什么选择？
谢谢！
编辑：自从我问这个问题已经有两个多月了。在这段时间里，我对应用程序进行了一些重要的重新架构和重构。在此过程中，我设法消除了应用程序中99％的事件聚合器使用率。我最终发现我对事件聚合器不必要的大多数用法（我有很多）。通过更好地组织应用程序，我能够消除事件聚合器消息，并且我还用可观察对象（某些出色的IMO）替换了一些消息。因此，如果有人发现这正在严重依赖事件聚合器，那么请退后一步，考虑一下您在做什么，因为可能有更好的方法！
答案 0 :(得分：0)
很显然，可以使用几种方法在类之间进行通信，但是我认为这很容易是的，很好。
您的事件聚合器基本上是一条消息总线，使用该概念在应用程序内进行通信没有错。有些东西是视图模型，而另一些模型并没有什么实际意义。因此，我认为一个就足够了。
话虽这么说，许多事件可能不是最好的选择（由于类型爆炸或魔术字符串，取决于您的框架，如果没有其他选择）。如果可以的话，我可以将消息定向到特定的接口（可能是事件接口，或基于事件类型的接口）和方法名称，并建立帮助程序类来解析消息并使用反射来调用适当的代码。过去，这种方法对我来说效果很好（尽管建立辅助类需要付出很多努力）。
要考虑的另一种方法是对所有模型类都使用依赖项注入容器，因此它们仅取决于他们尝试与之交谈的事物。主要缺点是将DI容器很好地集成到WPF中可能很困难。