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

Question

我们刚刚进入 WPF 中的 MVVM。

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

大部分情况下，类型转换都可以正常工作，因此输入数据非常简单。但是我们遇到了验证问题。

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

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

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

在我们看来，这两种方法根本不同，所以在我们决定之前，我们想了解一些 SO 对此事的知情意见。

那么：ViewModel 是否应该向视图公开一个简化的“基于文本”的界面并在内部处理转换？还是应该 ViewModel 属性公开实际的数据类型，让视图处理这些琐事？

更新：

在这里很难选出一个赢家，但我终于找到了一个或多或少像我一样总结的人。

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

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

事实上，在整个过程中留下 UI 的细节留给创意空间，此外，在我看来，即使是精心设计的设计也总是会在整个实施过程中发生变化。

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

各位，总而言之，这是一次很棒的讨论，有很好的表述，有见地的意见。谢谢。

Answer 1

这是一个非常有趣的问题，我觉得这个问题没有明确的答案，但我会尽我所能把我的想法发表出来。

查看我所理解的 MVVM 模式，ViewModel 的重点是以 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，因为它在模型中就是如此。您在问题中列出了这样做的缺点，但主要优点是它为视图的创建者提供了有关如何显示该数据的有价值的信息。请记住，我们（作为 ViewModel 的作者）不知道 View 的样子。通过承诺数据是 int 的想法，视图可以使用文本框或其他仅接受数字的控件（例如，拨号）来显示信息。如果我们说我们将以一种我们认为对 View 有帮助的方式来格式化数据，那么它就会失去这种重要的力量。

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

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

---

好吧，也许那不是最后......

我想对 Kent 制作的 cmets 发表讲话，但我的想法不适合发表评论。

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

我的观点是基于您应该能够交换视图的假设，它们应该是稍纵即逝的东西，可能会根据屏幕尺寸、硬件、平台、延迟和环境的要求而改变。有趣的转折是我从来没有真正需要这个功能，也没有看到任何曾经使用过它的东西（除了概念证明应用程序），但如果我们接受我们现在或以后不会使用它在未来的任何时候，每个 ViewModel 都将与一个，并且只有一个 View 一起工作，那么我们不妨回到将所有代码放在代码隐藏文件中并完全丢弃 ViewModel - 毕竟，它是如此紧密耦合，它也可能是同一个类。

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

Answer 2

出于所有常见原因，它绝对属于视图模型，包括：

• 设计人员拥有 XAML。您是否希望设计人员必须了解并实现必要的类型转换和验证逻辑？
• 可测试性。您不想验证您的转换和验证逻辑是否正常工作吗？如果它嵌入到视图中，那就更难了。

另一方面，从视图设计者的角度来看，转换、验证等将不那么具有声明性、明确性和灵活性

我认为这是一个有争议的问题，因为视图设计师应该对这些事情负责。设计师试图以某种方式使 UI 外观和感觉；是开发者实现业务逻辑，包括转换和验证逻辑。

Answer 3

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

是的。

视图模型是视图和模型之间的抽象层 - 执行任何类型转换（而不是繁琐的值转换器）的完美场所。验证绝对应该作为视图模型的一部分进行。

我们使用我们的视图模型来尽可能多地处理数据类型的转换。这减少了对某些非常特定情况的值转换器的需求。您想公开视图最容易使用的任何类型。这一直运作良好。

您提出的一个具体问题：

例如，如果一个非数字值是 在绑定到 a 的文本框中输入 数字属性，转换 失败，该属性永远不会被设置，并且 我们从来没有机会提供 给用户适当的反馈。更差， 该物业保留其当前 值，导致之间的不匹配 视图中显示的内容和 ViewModel 中的实际内容。

可以通过将视图模型类型公开为 可为空 类型来处理。即使输入了无效数据，这仍应允许更新基础源并触发验证。这与我们使用 DateTime 和日期时间选择器的情况类似。

保持视图愚蠢。我们没有官方设计师，我们的开发人员就是我们的设计师，所以保持视图不变有一些好处：

• 我们（开发人员）要保持理智（XAML 不那么冗长）
• 业务逻辑（包括验证）保留在视图模型中并且可以启用测试

祝你好运！

-Z

Answer 4

这是一个很好的问题，我当然可以看到讨论的双方。

我的想法是，您真正要寻找的是可以在 xaml 中使用的正确 NumericInputControl。这将提供更好的用户体验，因为您的用户将无法在数字字段中意外输入文本，并且由于控件在不验证的情况下限制输入，您可以维护更强类型的 ViewModel。

我不知道你想如何实现一个，我知道经典的微调器/NumericUpDown 控件正在失宠，因为它们不是触摸友好的，但我不相信引入这样的控件将违反设计方法或 ViewModel 的纯度。您将收到一个号码，然后您可以在适当的位置进行范围验证，像往常一样通过IDataErrorInfo 提供反馈，等等。 :) 这种技术可以让您在没有任何真正缺点的情况下获得两全其美（除了创建数字控件）。

Answer 5

或者 ViewModel 属性是否应该公开实际的数据类型，让视图处理这些琐事？

1. 转换和模板在View中完成，因为它们都只是将values、models和viewmodels转换成controls！ Controls 仅在 View 内部可用。

2. 验证在ViewModel中完成，因为验证是根据业务规则完成的，甚至可以通过调用远程服务来完成。 View 对业务规则一无所知，但知道如何呈现验证结果。

例如，如果在绑定到数字属性的文本框中输入了非数字值

精心设计的数字文本框控件绝不允许用户输入非数字值。