C# 让ViewModel调用操作而不是执行命令和发布事件？

在这个假设问题中，假设ViewModel发布了视图订阅的相当复杂的事件。然后，视图根据该事件中的状态操纵多个屏幕元素。例如，几个按钮被设置为可见/隐藏、启用/禁用，或者可能启动了故事板

// purely as an example:
public class SomeEvent
{
    public bool ShouldShowAddButton { get; set; }

    public bool ShouldShowDeleteButton { get; set; }

    public bool AddButtonEnabled { get; set; }

    public bool DeleteButtonEnabled { get; set; }
}

因为VM对视图一无所知，所以它实际上无法进入并执行这些操作，而是依赖于事件。我认为是标准的MVVM实践。（另一种选择是将这些项目中的每一项都作为它们自己的已发布事件，一个接一个地发送。）

但是，如果虚拟机可以在不了解视图的情况下调用视图呢

public class MyViewModel
{
    public Action OnShowAddButton { get; set; }
    public Action OnShowDeleteButton { get; set; }
    ...etc

    private void OnSomeStateChange()
    {
        // here, we'd normally publish the SomeEvent class
        // instead, we could just call OnShowAddButton (or whatever) instead
    }
}

public class MyView
{
    public MyView()
    {
        this.myViewModel.OnShowAddButton = () => ...;
        ...etc
    }
}

---

除了不是MVVM设计的“典型”之外，还有什么原因会让人不高兴吗？据我所知，它仍然保持着正确的分离水平。

我认为这种变化是混合了一点MVC和一点MVVM，尽管两者都不是。因此，模式的

模型视图

部分在您的方案中通过将模型直接注入视图实现中，然后通过事件发送某种命令来解决

然后，您需要通过在模型中提供可由视图直接设置的属性，或者通过在视图中公开一些事件并在模型中执行相同的注入，来解决或绕过模式的

视图模型部分

我想它会变丑的。即使模型只是一组可观察的实体，并且您从其他地方控制它们（控制器？：）

我已经可以看到代码，无数事件和属性混合在一起。。。但这完全取决于用户界面的复杂程度、视图的数量以及它们的复杂程度。在一个有10多个按钮和/或输入的视图中，我认为采用这种方法是个坏主意

我说，只要您没有专用的MVVM基础设施，如WPF或HTML，就没有必要实现自己的基础设施。仅仅用手工编码的框架是不可能达到如此漂亮的分离程度的。您需要一些支持来将UI代码与模型完全分离，进行绑定等等

也许你可以对你想用的东西多加评论。如果您在客户端框架（如HTML/JS）或Windows窗体实现中需要它，那么您可能会使用一些专用的解决方案，或者更好地说，您可以采用一些更简单的方法

这一切都来自一个在ASP.NET Web表单之上实现MVP变体的家伙。如果我能让时光倒流
 这个问题是在一个真实的C#+XAML项目中提出的。@moswald:那么我认为这完全没问题，因为你只是在扩展现有的MVVM功能。我有一种印象，你是在白手起家地写一些东西，而不是在考虑分离关注点。