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

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

我们已经使用我们在视图中绑定的“强类型”属性（int、double？等）实现了 ViewModel。

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

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

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

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

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

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

Update:

在这里很难选出一位获胜者，但我最终找到了一位或多或少像我一样得出结论的人。

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

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

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

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

总而言之，这是一次精彩的讨论，大家提出了精心制定的、见多识广的意见。谢谢。

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

从我理解的 MVVM 模式来看，ViewModel 的重点是以 View 可以理解的方式公开数据without关于视图将如何使用它的任何假设。举个例子，假设我们正在对汽车的速度进行建模：

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，因为这就是模型中的属性。您在问题中列出了这样做的缺点，但主要优点是它为视图的创建者提供了有关如何显示该数据的宝贵信息。请记住，我们（作为 ViewModel 的作者）不知道 View 是什么样子。通过将数据视为 int 的想法，视图可以使用文本框或其他仅接受数字的控件（例如拨号盘）来显示信息。如果我们说我们将以我们希望的方式格式化数据assume对视图有帮助，它会夺走它的重要力量。

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

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

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

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

显然，我和 Kent 的观点（据我理解）之间的主要区别是，他将 ViewModel 视为视图的模型，而我将其视为将模型公开给视图的东西。我承认这是一个微妙的差异，但我认为结果是我不想删除模型提供的信息，即使它使我正在使用的特定视图更容易。

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

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