wpf - MVVM ViewModel 是否应该执行类型转换/验证？

Question

我们刚刚开始了解 WPF 中的 MVVM。

我们已经使用绑定(bind)到 View 中的“强类型”属性(int、double？等)实现了 ViewModel。

大多数情况下类型转换工作正常，因此输入数据非常简单。但我们在验证方面遇到了问题。

如果在绑定(bind)到数字属性的文本框中输入非数字值，则转换会失败，该属性永远不会设置，并且我们永远没有机会向用户提供正确的反馈。更糟糕的是，该属性保留其当前值，导致 View 中显示的内容与 ViewModel 中实际显示的内容不匹配。

我知道，所有这些都可以通过值转换器来处理。但我看到了一些意见，大意是转换根本不应该是 View 的责任。 View 中输入的是字符串，转换、验证等应该是 ViewModel 的责任(所以论证是这样的)。

如果是这样，我们应该将 ViewModel 上的大部分属性重写为字符串，并通过例如 IErrorInfo 接口(interface)提供错误信息。它肯定会使 View 中的 XAML 变得更简单、更精简。另一方面，从 View 设计者的角度来看，转换、验证等将减少声明性、明确性和灵 active 。

在我们看来，这两种方法本质上是不同的，因此在我们做出决定之前，我们希望获得一些有关此事的知情意见。

那么:ViewModel 是否应该向 View 公开一个简化的、“基于文本”的界面并在内部处理转换？或者 ViewModel 属性是否应该公开实际的数据类型，将此类杂务留给 View 来处理？

更新:

这里很难选出一位获胜者，但我最终找到了一位或多或少与我相似的人。

具体来说，我们决定保留 ViewModel 属性的类型。其主要原因是它为我们提供了 View 设计的灵 active ，以及​​ XAML 中显式声明性转换/格式设置的功能。

我注意到您的一个假设在这方面不同意我们的观点，即 View 的设计已经固定并准备就绪。因此，不需要在 View 中做出有关转换、格式化等的决定。但我们的流程是敏捷的，我们还没有事先弄清楚 UI 的所有细节。

事实上，让 UI 的细节在整个过程中得到解决，为创造力留下了空间，而且，在我看来，即使是精心设计的设计，在整个实现过程中也总会发生变化。

所有这一切的要点是，虽然业务规则执行当然属于 ViewModel，但在我们看来，简单的转换和格式化是一个 View 事物。这可能听起来像异端邪说，但我实际上认为 View 中的类型转换根本不需要单元测试(只要我们对实际类型转换器进行单元测试)。

总而言之，大家进行了精彩的讨论，提出了精心阐述的、见多识广的意见。谢谢。

Answer 1

这是一个非常有趣的问题，我觉得没有明确的答案，但我会尽力表达我的想法。

根据我的理解，查看 MVVM 模式，ViewModel 的要点是以 View 可以理解的方式公开数据，而无需对 View 将如何使用它进行任何假设。举个例子，假设我们正在对汽车的速度进行建模:

public class CarModel
{
    public int MilesPerHour { get; set; }
}

public class CarViewModel
{
    private CarModel _model;

    public int MilesPerHour
    {
        get { return _model.MilesPerHour; }
        set { _model.MilesPerHour = value; }
    }
}

在上面的示例中，我将属性公开为 int，因为它在模型中就是这样。您在问题中列出了这样做的缺点，但主要优点是它为 View 的创建者提供了有关如何显示该数据的宝贵信息。请记住，我们(作为 ViewModel 的作者)不知道 View 是什么样子。通过将数据视为 int 的想法， View 可以使用文本框或其他仅接受数字的控件(例如拨号盘)来显示信息。如果我们说我们将以一种我们假设对 View 有帮助的方式来格式化数据，那么它就会失去这种重要的力量。

另一方面，我们在现实世界中工作。我们往往知道观点是什么。我们很少在同一个 ViewModel 上即插即用不同的 View ，并且将转换代码添加到 ViewModel 中更加容易。我认为这是不对的，但这并不意味着您不会找到我使用它的生产代码...

最后(我相信您知道这一点，但为了完成目的......)业务逻辑应该在ViewModel中完成。如果我们决定汽车的速度不应该超过 70 英里/小时，那么 View 就没有责任强制执行这一点。因此，您最终仍然会遇到某种错误提供程序，但处于业务级别而不是显示级别。

<小时/>

好吧，也许这还不是最后......

我想回应 Kent 的评论，但我的想法不适合评论。

显然，我和 Kent 的观点之间的主要区别(据我所知)是他将 ViewModel 理解为 View 的模型，而我将其理解为将模型公开给 View 的东西。我承认存在细微差别，但我认为结果是我不想删除模型提供的信息，即使它使我正在使用的特定 View 更容易。

我的观点基于这样的假设:您应该能够交换 View ，它们应该是转瞬即逝的东西，可能会根据屏幕尺寸、硬件、平台、延迟和环境的要求而改变。有趣的是，我从未实际上需要此功能，也没有见过任何使用过它的东西(除了概念验证应用程序之外)，但如果我们接受这一点，我们现在或将来不会使用它在未来的任何时候，并且每个 ViewModel 将与一个且仅一个 View 一起工作，那么我们不妨回去将所有代码放入代码隐藏文件中，并将 ViewModel 完全扔掉 - 毕竟，它是如此紧密耦合，它可能是同一类。

理想情况下，我希望 ViewModel 可以说“这个值是一个 int，它永远是一个 int，你可以用你喜欢的任何方式显示它。但是你可以把任何东西还给我和我”我会尽力使它适合，如果我不能，我会让你知道”。基本上我的 MilesPerHour 属性应该有一个 int getter，但有一个对象 setter。这样， View 就可以保留我认为他们需要的所有信息，但不必担心转换或验证。