为什么MVVM和它的核心好处是什么？
为什么我们在处理WPF时通过MVC或MVP去使用MVVM？
使用这个额外的好处是什么？
编辑：
说实话，今天我接受了一个采访，我被问到了这个问题。 我回答像INotifyPropertyChanged，ICommand，IValue转换器..但他不满意。 从今以后，我提出了这个问题
提前致谢
我会告诉你一个杰森·多林格特别有用的video 。
从一个WinForms世界来说，实现任何MVX风格的模式似乎比它的价值更麻烦，但在WPF工作了几年后，我可以诚实地说，我不会考虑更less。 整个范例是支持的。
首先，关键的好处是实现“观点”和“模式”之间的真正分离。 这实际上意味着，如果/当你的模型需要改变时，它可以不需要视图，反之亦然。
其次，虽然你的“模型”可能包含你在“视图”中可能需要的所有数据，但是你可能想要以“模型”不支持的方式来抽象这些数据。 例如，假设你的模型包含一个date属性。 在模型中，它可以完全作为DateTime对象存在，但是您的视图可能想要以完全不同的方式呈现它。 如果没有“视图模型”，您必须重复“模型”中的属性以支持视图或修改可能严重混淆“模型”的属性。
您还可以使用“viewmodel”来聚合模型中存在于单独的类/库中的部分，以便为“视图”处理更stream畅的界面。 你很可能不希望在你的代码中使用数据，就像用户希望或希望将数据提供给他们一样。
最重要的是，您可以获得对'view'和'viewmodel'之间自动双向数据绑定的支持。
真的有一大堆额外的东西可以让我震惊，但杰森说，我可以做得更好，所以我的build议是看video。 经过几天这样的工作，你会想，如果没有它，你会得到什么。
祝你好运。
这些是我特有的MVVM
- 增加视图的“可混合性” （使用Expression Blenddevise视图的能力）。 这使得有足够幸运的devise师和程序员的团队的责任分离……每个人都可以独立工作。
- “看不见”的观点逻辑 。 视图与运行在其后面的代码是不可知论的，使相同的视图逻辑可以在多个视图中重复使用，或者可以轻松地重组或replace视图。 分解“行为”与“风格”之间的关系。
- 没有重复的代码来更新视图 。 在代码隐藏中，你会看到很多调用“myLabel.Text = newValue”的地方。 使用MVVM，您可以放心，只需通过设置底层属性和所有视图的副作用来更新视图。
- 可测性 。 由于你的逻辑是完全不知道你的看法（没有“myLabel.Text”引用），unit testing是容易的。 您可以testingViewModel的行为而不涉及其视图。 这也启用了视图行为的testing驱动开发，使用代码隐藏几乎是不可能的。
其他两种模式在解决他们所关心的问题上确实是分开的。 你可以使用MVVM与MVP和MVC（最好的样本在那里做一些这样的forms）。
事实上，在我看来，MVP（具有被动视图，而不是监视控制器）实际上只是MVVM的一个变体。
WPF比任何其他的UI框架有更好的数据绑定，而MVVM将不受任何约束
MVVM提供了unit testing性和优秀的视图不可知性，这使它成为一件好事
烘焙支持ICommand和INotifyPropertyChanged是两个最大的好处。 使用MVVM使得连接命令和插入数据到WPF UI非常容易。 事情正常。
我personnaly看到MVVM不是一个好处，但作为一个谁想要使用WPF酷function的义务。
WPF的核心数据绑定非常庞大，使用户界面与模型分离。 但数据绑定技术上在WPF中完成的方式有点特别，因为它绑定到如下类：
- 的DependencyProperty
- INotifyPropertyChanged的
- 的ObservableCollection
正因为如此，使用标准的.NET技术就无法像你想要的那样写一个模型。 例如，WPF TreeView几乎不可能使用数据绑定和模板来使用w / o。 你只是不能像Winforms中的通用模型那样填充它。 它必须绑定到使用ObservableCollection表示节点的子节点的分层模型。
所以我们假设V表示XAML代码，它是代码隐藏的对象（所以它被视为一种技术绑定到WPF），让我们说M代表你的模型（所以它不是绑定到WPF UI技术）。
那么，你将永远不会在WPF下正常工作，只有这些V＆M。
你必须在两者之间添加一些东西。 WPF兼容的东西，理解你的模型。 说的是DependencyProperty，ObservableCollection和INotifyPropertyChanged。 这就是所谓的虚拟机。
作为一个方面说明，MVVM的替代scheme是构build一个V＆M（无VMpipe道）组合，M是WPF兼容的，但仍然具有合理的UI独立性。 从历史上看，ObservableCollection在WindowsBase.dll程序集（随附WPF）中，所以将一个通用模型绑定到与UI技术相关的东西看起来很奇怪。 因为它已经被移回到System.dll。 即使如此，有时很难保持一个纯粹的VM模型，而不是专门为WPF调整M …
XAML代码绑定数据的能力以及触发器的存在将打破MVP和MVC模式。
