在WPF中如何从其他ViewModel中引用MainWindowViewModel

当前直接引用方案的评估 #

• 优势：实现逻辑简单、无额外第三方依赖、调试链路直观，对页面数量少于5个、后续迭代需求少的中小规模个人项目完全适用，不需要强行重构。
• 劣势：PageViewModel与MainWindowViewModel强耦合，子页面VM无法在其他场景复用，后续新增导航相关逻辑（如权限校验、导航历史记录）时容易出现代码散改的问题。

方案一：抽象导航服务（优先推荐，中等规模项目适用） #

你可以通过依赖注入+接口抽象的方式轻量解耦，无需引入额外的事件机制：

1. 定义统一的导航接口

public interface INavigationService
{
    /// <summary>
    /// 导航到指定页面
    /// </summary>
    void NavigateTo(string pageIdentifier);
    /// <summary>
    /// 返回上一级页面
    /// </summary>
    void GoBack();
}

2. 让MainWindowViewModel实现该接口，所有导航逻辑统一收口在主VM中
3. 实例化PageViewModel时，将INavigationService实例注入到子VM中，子VM只需要调用接口方法即可完成导航，不需要感知具体的实现类，既降低了耦合度，也保留了逻辑的直观性。

方案二：IEventAggregator 适用场景 #

只有当你的项目符合以下特征时，才需要引入事件聚合器实现导航：

• 项目规模大，页面层级深、数量超过15个，存在大量跨多层级VM的通信需求
• 除了导航外，还有全局状态变更、全局通知广播等通用事件需求
  使用时只需要在MainWindowViewModel中订阅NavigationRequestEvent，子VM需要导航时发布带目标页面参数的事件即可，两边无需互相持有引用。注意如果使用的是第三方框架自带的IEventAggregator，大部分已经做了弱引用处理，无需手动取消订阅避免内存泄漏。

选型总结 #

• 个人小项目、无长期迭代需求：当前直接引用的方案可以继续使用，无需过度设计
• 中等规模、团队协作、有长期迭代需求：优先选择抽象导航服务的方案，比事件聚合器更贴合导航场景的语义，维护成本更低
• 大规模项目、存在大量跨VM通信需求：再考虑引入IEventAggregator

内容的提问来源于stack exchange，提问作者pgee70