c# - 如何正确定义 Model 到 ViewModel 的关系？

Question

我试图理解 Model 与 ViewModel 的关系，但我一直遇到同样的问题。假设我们有一个只有一个字段的“Person”类:

public class Person
{
   public string Name;
}

在下一阶段，我的 XAML 艺术家创建了一个用户控件来呈现一个 Person，根据 MVVM 的实践，他需要将他的 View 与 VMPerson(View-Model Person)相关联，所以现在我添加另一个类:

public class VMPerson : INotifyPropertyChange
{
   private Person person;

   public VMPerson():this(new Person()){}

   public VMPerson(Person person)
   {
      this.person = person;
   }

   public Name
   { get { return person.name; }
   { set { person.name = value; PropertyChange("Name"); }
}

所以现在我几乎已经完成了所有设置..但是我的 VM 类与我的模型类中的更改有何关系？如果我在模型中添加 INotifyPropertyChanged 并为“名称”添加一个属性，我最终会得到与我的 ViewModel 类非常相似的东西，一个我不需要的额外层。有没有什么办法可以让我的模型类保持原样，并且仍然在 View 模型类中收到有关它内部更改的通知？如果除了使用 INotifyPropertyChanged 机制或将在模型中实现的任何类似机制之外没有其他方法，为什么我需要 VM ？是否仅适用于将几个“模型”类聚合为一个将提供给 View 的类的情况？

我想我一定在理解上遗漏了一些东西，因为根据我的描述，在我看来，使用 View 代码隐藏作为 Controller 的模型到 View 模式比 MVVM 更好，但我当然不是确定这一点。有人可以向我解释我所缺少的吗？谢谢。

Answer 1

将 View 模型代码放入模型中并不是最好的主意

的确，在许多情况下， View 模型看起来像额外的代码层，实际上并没有增加任何值(value)，但关键是它们可以进化。

VM 的作用是为 View 提供便利——INotifyPropertyChanged 就是这样一种便利，而模型的作用是封装您的业务逻辑。随着代码功能的增长，功能会越来越丰富；在某些时候，它甚至可能最终在代码大小上比您的模型大得多。所以进行区分是为了让便利部分和业务逻辑部分很好地分开，这对代码的可维护性有很好的影响。

将 View 模型代码放入 View 中并不是最好的主意

这里的原因是不同的:如果你这样做然后需要将 View 模型与另一种类型的 View 一起使用，你将不得不将所有逻辑也复制到其他 View 的代码隐藏中。重复是不好的； DRY 很好。

考虑到 MVVM 的一个非常重要的特性是它提供了可测试性，而可测试性必然意味着至少两种类型的 View (真实 View 和模拟 View )，这种方法的必要性变得显而易见。