C# 我应该为每个模型提供一个封装的ViewModel吗？

我最近一直在与WPF和MVVM合作。我的印象是我非常了解MVVM模式，但我开始有一些怀疑

现在，每个模型对象都有一个封装的ViewModel对象。 假设我的模型包含两个类：

Property

，其中包含

PropertyValue

的列表。在我的ViewModel中，我有一个

PropertyVm

，其中包含一个

Property

和一个

PropertyValueVm

列表（每个都包含一个

PropertyValue

）。这两个Vm都实现了一个

BaseVm

，其中包含

OnPropertyChanged

方法

考虑一个包含两个组合框的视图，分别用于

属性

和

属性值

。第一个组合框的

ItemsSource

将绑定到

PropertyVm

的集合，第二个组合框的

ItemsSource

将绑定到组合框1中选择的

PropertyVm

的

PropertyValueVms

这一切都基于一篇文章，这篇文章让我首先探讨了WPF和MVVM：

然而，我对我的项目中包含的大量ViewModel类越来越恼火，其中一些只包含很少的代码，或者只包含相应的模型类

我遇到的其他实现在模型对象上更改了

INotifyPropertyChanged

。这意味着您将直接将模型对象指定给组合框。这将减少ViewModel类的数量，但这是否违反了MVVM的基本原则

我还看到有人提倡每个视图使用一个视图模型。但我担心这会把我的ViewModel类变成巨大的、不连贯的文本墙

---

简而言之，我的问题是：每个模型是否都应该有一个封装的ViewModel？如果不是，那么什么是最佳实践？

MVVM的主要驱动因素是通过表示和表示逻辑的强大分离来最大化可测试代码。理想情况下，我们将表示逻辑封装在一个或多个视图模型中——因此就您的子问题而言，尽可能多的视图模型是合理的。根据我的经验，将功能划分为一系列较小的视图模型是一个很好的实践。但要实现这一点，没有一刀切的方法。所以在某些方面，这个问题的答案是：这取决于你的处境

如果你的模式从未改变，那么你已经走到了宗教的岔路口。实用主义者将模型公开给UI绑定（有罪！！）。纯粹主义者将模型包装在视图模型中，因为VM在设计中位于M和V之间，如果我们不教条地遵守这一点，那么坏事肯定会发生

---

如果您的模型发生更改，则您可以选择设计。您可以保持模型不变，并使用模型的新版本刷新视图模型，并从中引发更改。或者，如果你的架构有助于用户界面需要更新的模型，那么问问你自己，你是否真的在中间粘贴了视图模型。但是只要你嗅到模型中潜入的逻辑，那么它就值得一个视图模型。

我认为你考虑得太多了。我建议为每个视图使用ViewModel。我认为在ViewModel中“包装”模型类没有任何优势。为继承自具有所有propertychanged通知功能的baseviewmodel类的每个视图创建一个ViewModel。然后将视图所需的任何模型类作为视图绑定到的公共属性公开。ViewModel的其余部分将包含您的业务逻辑方法。。。