我做了一些功课，找不到任何关于何时使用每种方法的最佳实践的文章。
只是为了澄清： 当使用事件聚合器模式时：每个屏幕都有它自己的视图模型引用，视图模型使用 eventtaggregator 发布更改，稍后观察者使用它来同步他们的状态。
缓存视图模型：每个屏幕都有视图模型的保存引用，绑定到视图模型属性的控件是同步的，因为应用程序中的每个屏幕都有相同的视图模型引用（从缓存中获取），所有由于数据绑定，屏幕是同步的。
何时使用每种方法？使用它们每个的优点是什么？
问问题
610 次
3 回答
1
好吧，正如我所见，事件聚合器方法更具可扩展性，并提供了更加解耦的设计。
当可伸缩性不是问题时，单个 VM（或多个 VM 缓存）方法很好，因为随着添加越来越多的视图，VM 可能会增长到惊人的比例。
总之，事件聚合器方法是经久耐用的系统的“正确”方法，但如果您正在为特定的有限目的和生命周期构建内部工具，则可以使用更简单的方法。
于 2009-12-27T11:02:40.577 回答
1
另一个适用于公共数据的选项是直接绑定到单个Observer类，该类公开必要的属性，而不是在需要同步的多个视图模型中具有重复的属性。
虽然使用观察者比订阅/发布事件聚合器耦合度更高，但当使用 IOC 容器注入观察者接口时，耦合仍然相当松散，并且很容易确定哪些视图模型依赖于哪些观察者。
于 2010-03-10T06:51:49.260 回答
0
感谢您的快速回复！只有当相同的VM类用于多个屏幕并且满足每个屏幕的合同时，您所说的才是正确的（在这种情况下，vm可能包含冗余字段，这些字段在某些绑定到它的屏幕中不使用）。
但是当你使用组合时，这种情况很容易解决，使用更细粒度的方法......
顺便说一句，我同意事件聚合器更加解耦......还有其他考虑因素吗？
于 2009-12-27T12:11:46.140 回答