鉴于以下情况：
通过构造函数注入将 ViewModelA 简单地注入 ViewModelB 并直接设置属性是不是很糟糕？
或者……</p>
是否应该使用像 Prism 的 EventAggregator 这样的消息系统来处理 ViewModel 之间的所有通信？
我喜欢注射方法，因为它很简单，但我的直觉告诉我我错过了一些东西。我呼吁你们的集体智慧来帮助填补我的盲点。
如果您需要双向引用，我认为这是一种代码异味。通常您可以用事件替换其中一个引用。
让 ViewModelB 引发 ViewModelA 订阅的事件。像在 Prism 中找到的那样完整的消息传递系统当然是一种选择，但在您的场景中，听起来像“正常”事件就可以了。
我建议你阅读这个问题（和我的答案），因为它很相似，但不完全是你的问题。它确实处理父/子 ViewModel 对象之间的属性通信。
让我们看一个基本的例子：
ViewModelA是父级，必须在 B 上显示某些属性的总和ViewModelB是孩子并且有一个需要求和的属性所以用户请求编辑 B 上的属性并且请求成功，所以 B 可能会更改其属性的值并触发一个PropertyChanged事件。
ViewModelA可以订阅所有孩子的事件，但是沿着这条路走下去，我不喜欢它。当添加和删除孩子时，您需要做大量的簿记工作。
将 A 注入 B 更干净，但您仍然需要做很多簿记工作。如果您对 A 执行“清除儿童”操作怎么办？您必须记住在所有情况下都正确摆脱从 B 到 A 的父关系。在我看来，它仍然比事件更好，因为它更明确。
我个人喜欢消息传递的想法。我比 Prism 更熟悉 MVVM Light 的信使，但它的想法是一样的……全局消息总线。在任何时候，任何 B 都可以说“我改变了我的财产！” 然后 A 监听通知并自己进行计算。我认为这是您最干净的解决方案，而且簿记要少得多。
我建议使用更轻量级的专用Messaging解决方案，称为“ Light Message Bus ”。它不是任何另一个 ;-) MVVM 框架的一部分，而是独立的组件。我在不到 3 分钟的时间内就让它工作了。
您可能会发现WPF 应用程序框架 (WAF)的示例应用程序很有用。ViewModel 彼此不了解。它们之间的中介由Controllers完成。这样可以防止 ViewModel 对象之间的循环依赖。