WPF MVVM中自定义对话框实现的MVVM合规性疑问

我正在为项目学习MVVM，提前梳理复杂模块以掌握其原理。目前在对话框（尤其是自定义对话框和消息框）的实现上遇到困惑：我通过按钮触发ViewModel中的命令，该命令调用View在DataContext变更时注入的Func来获取Pile对象并添加到列表中。相关代码如下：

private void OnAdd()
{
    Pile? pile = GetPileToAdd?.Invoke();
    if (pile is null) return;
    Piles.Add(pile);
}

private void PileScreenView_DataContextChanged(object sender, DependencyPropertyChangedEventArgs e)
{
    if (e.NewValue is PileScreenViewModel psvm)
    {
        psvm.GetPileToAdd = () =>
        {
            MessageBox.Show("getting pile");
            return new Pile() { Name = "Name", Length = 0 };
        };
    }
}

后续会将MessageBox.Show替换为自定义对话框。我的疑问是：这种实现是否符合MVVM规范？另外，直接在View中实例化Model是否允许？

回答 #

关于实现是否符合MVVM规范 #

你的这种实现思路本质上是符合MVVM分离原则的，但细节上有优化空间：

• 核心逻辑是ViewModel通过委托（Func）委托View处理UI相关的对话框交互，ViewModel本身不直接依赖UI组件，这避开了MVVM中ViewModel不能直接操作View的禁忌，方向是对的。
• 但当前通过DataContextChanged事件注入委托的方式，会让View和ViewModel产生隐性绑定。更好的做法是通过**依赖注入（DI）**或者专门的对话框服务（DialogService）来封装对话框逻辑，让ViewModel通过服务接口调用，而不是直接持有View注入的委托，这样ViewModel的可测试性会更强——单元测试时可以轻松Mock这个服务，不用依赖View的存在。

关于View中实例化Model是否允许 #

严格来说，MVVM并没有完全禁止View实例化Model，但这不是推荐的做法：

• Model代表业务数据和业务规则，如果在View中实例化Model，容易让View渗透进业务逻辑，破坏View只负责UI展示和用户交互的职责边界。
• 更合理的做法是：要么由ViewModel负责实例化Model（因为ViewModel本来就处理业务逻辑相关的协调工作），要么通过专门的业务服务来创建Model，再由ViewModel调用该服务获取实例。这样能保证业务逻辑的集中管理，也方便后续的测试和维护。

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