silverlight - ViewModel 事件注册和 ViewModel 生命周期

Question

我有一个架构问题，以及一个我想提出意见的可能解决方案。

我习惯于 WP7 的 MVVM 架构(尽可能但不幸的是，有时 sdk 似乎朝着相反的方向发展)。

WP7 强制采用 ViewFirst 方法，我对此感到满意(除了我们无法覆盖 View 创建的部分，如在 Silverlight 中，以使构造函数注入(inject)成为可能)。
通过让大部分 View 模型遵循其 View 的生命周期，我发现自己很有信心。因此， View 模型是在创建 View 时创建的(通过访问 ViewModelLocator)， View 模型(或应该)仅由其 View 引用，当 View 被销毁时，它的 ViewModel 也应该被销毁(它不是强制性的，但它的方式我去除非在极少数情况下我创建一个单例 View 模型)。

我的 View 模型可能需要注册一些单例服务事件(我创建的电话服务或单例类)。我的意思是，它可能需要注册到一个生命周期不是由 View 模型本身决定的类的事件。
这些事件保持对我的 View 模型的硬引用，即使 View 被破坏，我的 View 模型也将继续接收和处理事件。
WeakEvent 模式可能是一种可能的解决方案，但为每个事件创建一个事件管理器是不切实际的。在我看来，最好的解决方案是不存在的，应该是对事件进行弱注册的关键字。

我找到的一个解决方案是让我的 View 模型知道 NavigateTo 和 NavigateFrom，这样我就可以从那里注册和取消注册事件。我还可以添加一些逻辑(例如，我只能在返回的情况下取消注册)将注意力放在 NavigateTo 和 NavigateFrom 中具有镜面反射逻辑。

另一种可能的方法(我没有测试过)可能是让我的 View 模型知道 View 终结，并在 View 终结时执行一些清理，但我总是觉得由于使用终结，不推荐这种方法。我也不清楚性能会受到多大影响。

您如何看待让 View 模型的生命周期与其 View 相同(直到现在它一直简化我的应用程序)？
您如何看待 NavigateTo-NavigateFrom ViewModel 感知解决方案？
您如何看待 View-Finalization ViewModel 感知解决方案？
您是否经历过这些或其他类型的解决方案？

问候
天空G

更新

我发现最终确定解决方案无法完成工作，因为它可能会在以后发生(或者可能永远不会发生)。
目前在我看来，最好的解决方案是 viewmodelbase Initialize 和 Cleanup 中的一对虚拟方法，用于 View 应该调用的事件注册注销。
调用它们的可能时刻可能是在加载和卸载事件期间(如果我在后续 View 中不需要我的 View 模型处理事件，在这种情况下，第一个 View / View 模型在后台堆栈中仍然存在但如果它们的 View 附加/分离到可视树，则会触发加载/卸载)。

任何其他意见(甚至是肯定的)将不胜感激。

谢谢你

Answer 1

What do you think about having the viewmodel lifetime be the same as its view (it always simplified my app until now) ?

这听起来很合理，因为它与 DataContext 直接相关。的看法。

What do you think about the NavigateTo-NavigateFrom ViewModel aware solution ?

我不认为这是一个好主意。在 MVVM 模式中，ViewModel 应该对 View 一无所知。导航通常与 View 相关，所以我认为这不是最好的主意。

What do you think about the View-Finalization ViewModel aware solution ?

没有专门讨论最终确定， View 模型的清理方法是 IMO 的必经之路。在所有 ViewModel 的基类中(我希望你有一个)，你可以放置以下方法:

public abstract class ViewModelBase
{
    ....
    public virtual void Cleanup();
}

然后，只需调用 myViewModel.CleanUp();当您的 View 关闭时。
在 CleanUp 的具体实现中取消注册您的事件:

public override void CleanUp()
{
    ....Event -= this....EventHandler;
}