为什么在处理 WPF 时我们选择 MVVM 而不是 MVC 或 MVP?
使用 MVVM 会带来哪些额外的好处?
编辑:
老实说,今天我参加了一次面试,被问到了这个问题。我回答了 INotifyPropertyChanged,ICommand,IValue Convertor 等等,但他并不满意。因此我提出了这个问题。
提前感谢。
我向您介绍一段由Jason Dolinger制作的特别有用的视频。
从WinForms世界过来,实现任何MVX风格的模式似乎比它值得的麻烦多了,但是在现在使用WPF工作了几年之后,我可以诚实地说,我不会考虑任何低于这个标准的东西。整个范式都支持开箱即用。
首先,关键的好处是在view
和model
之间实现真正的分离。在实际操作中,这意味着如果/当你的model需要变化时,视图不需要改变,反之亦然。
其次,虽然你的model
可能包含在视图中所需的所有数据,但你可能希望以这样一种方式抽象化这些数据,使得model
不支持。例如,假设你的model包含一个日期属性。在该model中,它可以仅存在为DateTime
对象,但是视图可能想要以完全不同的方式呈现它。如果没有viewmodel
,你要么必须在model
中复制该属性以支持视图,要么修改该属性,这可能会严重混淆“model”。
你还可以使用一个viewmodel
来聚合你模型中存在于不同类/库中的部分,以促进更流畅的view
接口处理。很不可能您希望以与用户相同的方式处理数据或者希望以相同的方式呈现数据。
除此之外,你还获得了在view
和viewmodel
之间自动双向数据绑定的支持。
实际上,我可以谈论很多额外的东西,但是Jason表达得比我好,所以我的建议是观看视频。几天后,你会想知道你以前怎么能没有它。
祝你好运。
以下是特定于MVVM的优点:
另外两种模式实际上是针对解决的问题而分开的。您可以使用MVVM与MVP和MVC(大多数好的示例都会使用某种形式的这种结构)。
实际上,在我看来,MVP(使用被动视图而不是监控控制器)只是MVVM的一种变体。
WPF拥有比其他任何UI框架更好的数据绑定功能,MVVM没有这个功能会变得难以控制。
MVVM提供了单元测试和优秀的视图无关性,使其成为一个不错的使用选择。
内置支持ICommand和INotifyPropertyChanged是最大的优点。使用MVVM模式可轻松将命令与WPF UI连接并插入数据。一切都很顺畅。
我个人认为MVVM不是一种好处,而是一种义务,对于那些想要使用WPF酷炫功能的人来说。
WPF非常重视数据绑定,以实现UI与模型的分离。但是,在WPF中技术上完成数据绑定的方式有些特殊,因为它与类(如DependencyProperty、INotifyPropertyChanged和ObservableCollection)紧密相连。
所以,假设V代表XAML代码及其代码后台(因此它与WPF作为技术相关联),而M代表您的模型(因此它与WPF UI技术没有任何关系)。
那么,在WPF下,只有这些V和M,您永远无法使其正常工作。
在这两个之间,您必须添加一些东西。一些WPF兼容并且理解您的模型的东西。一些能够处理DependencyProperty、ObservableCollection和INotifyPropertyChanged的东西。这就是所谓的VM。
另外,MVVM的替代方案是使用V&M(没有VM管道)与M兼容WPF,但仍具有合理的UI独立性的组合。从历史上看,ObservableCollection在WindowsBase.dll程序集中(随WPF一起发布),因此将通用模型绑定到与UI技术相关联的对象似乎非常奇怪。它已经移回到System.dll中。即使如此,有时候也很难保持一个纯粹的VM模型,而不对M进行特定于WPF的调整...
XAML 代码的数据绑定能力以及触发器的存在将会破坏 MVP 和 MVC 模式。