屏幕同步 - 事件聚合器 VS 缓存 ViewModel 参考
我做了一些作业，但找不到任何关于何时使用每种方法的最佳实践的文章..
只是为了澄清： 使用事件聚合器模式时：每个屏幕都有自己的视图模型引用，视图模型使用事件聚合器发布更改，稍后观察者使用事件聚合器来同步其状态。
缓存ViewModels：每个屏幕都有viewmodel的保存引用，与viewmodel属性绑定的控件是同步的， 因为应用程序中的每个屏幕都具有相同的视图模型引用（从缓存中获取它们），所以由于数据绑定，所有屏幕都是同步的。
何时使用每种方法？使用它们各自的优点和缺点是什么？
i did some homework and couldn't find any article about best practices about when to use each method..
just for clarification:
When using the event aggregator pattern : each screen has it's own reference of a viewmodel, the viewmodel publish changes using the eventaggregator, which later the observers use to synchronize their state.
Caching ViewModels : every screen has the save referece of the viewmodel, the controls which are bound to the properties of the view model are synchronzied,
because every screen in the app has the same reference of the viewmodel (got them from a cache), all the screens are synchronized thanks to databinding.
when to use each approach? what are the pro's con's of using each of them?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
嗯，正如我所见，事件聚合器方法更具可扩展性，并提供了更加解耦的设计。
当可扩展性不是问题时，单个虚拟机（或多虚拟机缓存）方法是很好的，因为随着越来越多的视图的添加，虚拟机可能会增长到巨大的比例。
总之，事件聚合器方法是持久构建系统的“正确”方法，但如果您正在为特定的有限目的和生命周期构建内部工具，则可以使用更简单的方法。
Well, as I see it, the event aggregator approach is more scalable and provides for a more decoupled design.
The single VM (or multiple VM caching) approach is good when scalability is not an issue, as the VM may grow to monstrous proportions as more and more views are added.
In summary, the event aggregator approach is the 'correct' approach for systems built to last, but you may use the simpler approach if you are building an internal tool for a specific limited purpose and lifetime.
另一个适用于通用数据的选项是直接绑定到单个 Observer 类公开必要的属性，而不是在需要同步的多个视图模型中具有重复的属性。
虽然使用观察者比订阅/发布事件聚合器耦合性更强，但当使用 IOC 容器注入观察者接口时，耦合仍然相当松散，并且很容易确定哪些视图模型依赖于哪些观察者。
Another option which works well for common data is to bind directly to a single Observer class that exposes the necessary properties rather than having duplicated properties in multiple viewmodels that need to be synchonised.
While using an observer is more coupled than subscribing/publishing to the event aggregator, when observer interfaces are injected using an IOC container, the coupling still stays fairly loose and it is very easy to determine which viewmodels are dependent on which observers.
感谢您的快速回复！
仅当同一个 VM 类用于多个屏幕，并且满足每个屏幕的约定时，您所说的才是正确的（在这种情况下，vm 可能包含冗余字段，这些字段在绑定到它的某些屏幕中不使用） ）。
但是当您使用组合并使用更细粒度的方法时，这种情况很容易解决...
顺便说一句，我同意事件聚合器更加解耦...
还有其他考虑吗？
thanks for the quick reply!
what you're saying is true only if the same VM class is used for multiple screen, and satisfies the contract for each of them (in this situation the vm might contain redundant field, which aren't used in some screens that bind to it).
but this situation is easily fixed when you use composition, using a more grained approach...
btw, i agree that event aggregator is more decoupled...
any other considerations?