1

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

// 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; }
}

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

但是，如果 VM 可以在不了解 View 的情况下调用 View 怎么办？

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 设计的“典型”之外，是否有理由对此表示不满？据我所知，它仍然保持正确的分离水平。

4

1 回答 1

0

我认为这种变体将一点 MVC 与一点 MVVM 混合在一起，尽管两者都不是。因此，Model-View通过将模型直接注入视图实现，然后通过事件发送某种命令，在您的提案中解决了模式的一部分。

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

我认为它会变得丑陋。即使模型只是一组可观察的实体并且您从其他地方控制它们（控制器？:)）。

我已经可以看到代码，无数的事件和属性混合在一起......但这一切都取决于你的 UI 将变得多复杂，你将拥有多少视图以及它们将变得多复杂。在具有 10 多个按钮和/或输入的视图中，我认为采用这种方法是个坏主意。

我说，只要您没有专用的 MVVM 基础架构，例如 WPF 或 HTML，就没有必要实现自己的基础架构。仅使用手动编码的框架是无法达到如此美妙的分离程度的。您需要一些支持才能将 UI 代码与模型完全分离、进行绑定等。

也许您可以对要使用它的内容发表更多评论。如果您需要它用于客户端框架（如 HTML/JS）或 Windows 窗体实现，那么可能有一些您可以使用的专用解决方案，或者更好的是，您可以采用一些更简单的方法。

这一切都来自一个在 ASP.NET Web 窗体之上实现 MVP 变体的人。如果我只能让时间倒流。

于 2013-05-27T19:04:13.943 回答