我最近一直在与WPF和MVVM合作。我的印象是我非常了解MVVM模式，但我已经开始怀疑了。
现在，我为每个Model对象提供了一个封装的ViewModel对象。
我们说我的模型包含两个类：Property，其中包含PropertyValue列表。在我的ViewModel中，我有一个PropertyVm，其中包含Property和PropertyValueVm列表（每个包含PropertyValue）。 Vm都实现了BaseVm，其中包含OnPropertyChanged方法。
考虑使用两个组合框的视图，Property和PropertyValue。第一个组合框的ItemsSource将绑定到PropertyVms的集合，第二个组合框的ItemsSource将绑定到PropertyValueVms的{{1}}在组合框1中选择{1}}。
这完全基于让我首先探索WPF和MVVM的文章：Simplifying the WPF TreeView by Using the ViewModel Pattern, by Josh Smith
然而，我对我的项目所包含的大量ViewModel类变得越来越恼火，其中一些包含非常少的代码或只是相应的Model类。
我遇到的其他实现代替了Model对象上的PropertyVm。这意味着您可以直接将Model对象分配给Comboboxes。这会减少ViewModel类的数量，但这是否违反了MVVM的基础知识？
我也看到人们提倡每个View一个ViewModel。但是我担心这会把我的ViewModel课程变成大量不连贯的文本。
所以我的问题简而言之：我是否应该为每个模型封装ViewModel？如果没有，那么最佳做法是什么？
答案 0 :(得分：6)
MVVM的主要驱动力是通过强大的表示和表示逻辑分离来最大化可测试代码。理想情况下，我们将表示逻辑封装在一个或多个视图模型中 - 因此就您的子问题而言，拥有尽可能多的视图模型是有意义的。根据我的经验，将功能划分为一系列较小的视图模型是很好的做法。但实现这一点并没有一刀切的方法。所以在某些方面，问题的答案是：这取决于你的情况。
如果你的模特永远不会改变那么你就已经到了道路上的宗教分叉。实用主义者将模型暴露给UI绑定（有罪!!）。纯粹主义者将模型包装在视图模型中，因为VM在设计中位于M和V之间，如果我们没有教条地坚持这一点，那么肯定会发生坏事。
如果您的模型发生变化，那么您就有了设计选择。您可以使模型保持不变，并使用新版本的模型刷新视图模型，并从那里引发更改。或者，如果您的体系结构促进了UI只需要表示的更新模型，那么可以通过在中间粘贴视图模型来问自己是否真正获益。但！！一旦你对模型中的逻辑嗤之以鼻，那么它就值得一个视图模型。