MVVM模式下能否在ViewModel中调用View的方法？如何实现？

核心可行性结论 #

• 从纯技术实现角度，哪怕目标方法是private修饰的私有方法，你通过反射、强转持有View实例的方式确实可以硬触发方法执行，但这属于完全违背MVVM架构设计原则的反模式，长期维护成本极高，不具备工程可行性。
• 从架构合规性角度，这类操作完全不可取。MVVM的核心边界是单向依赖：View层可以感知、绑定ViewModel的属性与命令，但ViewModel必须完全对View层的存在无感知。一旦ViewModel反向持有View引用、调用View的内部方法，就会形成双向强耦合，后续的单元测试、模块复用、故障排查效率会大幅下降。

针对你提供的 MyMethod 代码的具体分析 #

你写的这个MyMethod方法，本身承载的逻辑完全没有必须依托View层UI控件才能完成的部分，根本不需要跨层在ViewModel中调用：

private void MyMethod(object sender, EventArgs e)
{
    Book book = null;
    if (sender is StackLayout)
    {
        book = ((StackLayout)sender).BindingContext as Book;

        if (null == viewModel.BookSelected || !book.BookId.Equals(viewModel.BookSelected.BookId))
        {
            //Do something
        }
    }
}

拆解来看方法做了三件事：

1. 从触发事件的StackLayout控件实例中，提取出绑定在该控件上的Book实体
2. 对比当前ViewModel中存储的已选书籍ID，和当前提取到的书籍ID是否一致
3. 触发对应的后续业务逻辑
   这里面的每一步，都可以完全下沉到ViewModel层实现，不需要保留在View的代码后置中，更不需要让ViewModel反向调用：

• 针对从事件源提取Book实体的逻辑，可以通过XAML的命令绑定能力，直接把当前StackLayout对应的Book对象作为CommandParameter透传到ViewModel的绑定命令中，省去View层手动做类型判断、取BindingContext的适配代码。
• 针对书籍选中状态的对比判断逻辑，属于纯业务规则，本来就应该由ViewModel持有处理，不属于View层的职责范围。
• 你提到的「View可以访问到ViewModel无法获取的内容」的场景，正确的处理方式不是让ViewModel反向调用View方法，而是通过接口抽象、依赖注入、事件聚合器的模式，把ViewModel需要的能力抽象成独立的服务接口，由View层实现这个接口并注册到全局容器中，ViewModel只依赖抽象接口，完全不感知具体的View实例。

常见实践误区 #

• 不要把代码后置当成所有UI交互逻辑的默认存放位置：像点击卡片选中书籍这类常规交互，完全可以通过命令绑定打通UI和ViewModel的链路，不需要在View层写冗余的事件处理方法。
• 不要把跨层硬调用当成快速解决问题的捷径：一旦ViewModel持有View的引用，后续为ViewModel编写单元测试时，就必须模拟完整的View实例、甚至模拟私有方法的执行流程，测试难度会陡增。

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