我应该为每个模型封装一个ViewModel吗？

Question

我最近一直在使用WPF和MVVM.我的印象是我非常了解MVVM模式,但我开始有些疑惑.

现在,我为每个Model对象都有一个封装的ViewModel对象.假设我的模型包含两个类:Property其中包含一个列表PropertyValue.在我的ViewModel中,我有一个PropertyVm,其中包含一个Property和一个列表PropertyValueVm(每个包含一个PropertyValue).两个Vm都实现了BaseVm包含该OnPropertyChanged方法的方法.

考虑一个带有两个组合框的视图,用于Property和PropertyValue.第一组合框的ItemsSource将被绑定到的集合PropertyVms和所述第二组合框的ItemsSource将被结合到PropertyValueVms所述的PropertyVm选定的组合框在1.

这完全基于让我首先探索WPF和MVVM的文章:使用ViewModel模式简化WPF TreeView,作者:Josh Smith

但是,我对我的项目包含的大量ViewModel类变得越来越恼火,其中一些包含非常少的代码或者只是相应的Model类.

我遇到的其他实现INotifyPropertyChanged代替了Model对象.这意味着您可以直接将Model对象分配给Comboboxes.这会减少ViewModel类的数量,但是这不违反MVVM的基础知识吗？

我也看到人们提倡每个View一个ViewModel.但是我担心这会把我的ViewModel类转变为庞大,不连贯的文本墙.

简而言之,我的问题是:我是否应该为每个模型封装一个ViewModel？如果没有,那么最佳做法是什么？

Answer 1

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

如果你的模型永远不会改变那么你就已经达到了道路上的宗教分叉.实用主义者将模型暴露给UI绑定(有罪!!).纯粹主义者将模型包装在视图模型中,因为VM在设计中位于M和V之间,如果我们没有教条地坚持这一点,那么肯定会发生坏事.

如果您的模型发生变化,那么您有设计选择.您可以使模型保持不变,并使用新版本的模型刷新视图模型,并从那里引发更改.或者,如果您的体系结构促进了UI只需要表示的更新模型,那么可以通过在中间粘贴视图模型来问自己是否真正获益.但!!一旦你对模型中的逻辑嗤之以鼻,那么它就值得一个视图模型.