wpf 为什么选择 MVVM，它的核心优势是什么？

Why MVVM and what are it's core benefits?

提问by priyanka.sarkar

Why we go for MVVM over MVC or MVP while dealing with WPF?

为什么我们在处理 WPF 时选择 MVVM 而不是 MVC 或 MVP？

What extra benefit we get by using this?

使用它我们可以获得什么额外的好处？

Edit:

编辑：

To be honest , today I had an interview and I have been asked this question. I answered like INotifyPropertyChanged , ICommand,IValue Convertor.. but he was not satisfied. Henceforth I have put up this question

老实说，今天我接受了采访，我被问到了这个问题。我回答像 INotifyPropertyChanged , ICommand,IValue Convertor .. 但他不满意。从今以后我提出了这个问题

Thanks in advance

提前致谢

回答by EightyOne Unite

I'll point you to a particularly useful videoby Jason Dolinger.

我将向您介绍Jason Dolinger 的一个特别有用的视频。

Coming from a WinForms world, implementing any MVX style pattern seemed like more hassle than it was worth but after working with WPF for a couple of years now, I can honestly say that I wouldn't consider anything less. The whole paradigm is supported out-of-the-box.

来自 WinForms 世界，实现任何 MVX 样式模式似乎比它的价值更麻烦，但在使用 WPF 工作几年之后，我可以诚实地说我不会考虑任何更少的事情。整个范式都是开箱即用的。

First off, the key benefit is enabling true separation between the viewand model. What that means in real terms is that if/when your model needs to change, it can without the view needing to and vice-versa.

首先，主要好处是实现view和之间的真正分离model。这实际上意味着，如果/当您的模型需要更改时，它可以不需要视图，反之亦然。

Secondly, while your modelmay contain all the data you might need in your view, you may want to abstract that data in such a way that your modeldoesn't support. For example, say your model contains a date property. In the model it can exist solely as a DateTimeobject but your view might want to present it in a completely different way. Without the viewmodelyou'd either have to duplicate the property in the modelto support the view or modify the property which could seriously obfuscate the 'model'.

其次，虽然你model可以包含所有你可能需要在你的数据view，你可能要抽象的，在这样的数据，你的model不支持。例如，假设您的模型包含日期属性。在模型中，它可以单独作为一个DateTime对象存在，但您的视图可能希望以完全不同的方式呈现它。如果没有，viewmodel您要么必须复制 中的属性model以支持视图，要么修改可能严重混淆“模型”的属性。

You can also use a viewmodelto aggregate parts of your model that exist in separate classes/libraries to facilitate a more fluent interface for the viewto deal with. It's veryunlikely that you'll want to work with data in your code in the same way that a user will want to or will want that data presented to them.

您还可以使用 aviewmodel来聚合存在于单独的类/库中的模型部分，以促进更流畅的接口进行view处理。这是非常不可能的，你会想用同样的方式，用户将要或将要呈现给他们的数据代码数据的工作。

On top of that, you get support for automatic two-way data binding between the viewand viewmodel.

最重要的是，您可以获得对view和之间自动双向数据绑定的支持viewmodel。

There really is a whole bunch of extra stuff that I could bang on about but Jason say's it farbetter that I could so my advice is watch the video. After a few days of working like this, you'll wonder how you ever got by without it.

真的有一大堆额外的东西我可以说，但杰森说我能做的要好得多，所以我的建议是观看视频。像这样工作几天后，你会想知道没有它你是怎么过的。

Good luck.

祝你好运。

回答by Anderson Imes

These are mine specific to MVVM

这些是我特定于 MVVM 的

1. Increases the "Blendability" of your views(ability to use Expression Blend to design views). This enables a separation of responsibilities on teams that are lucky enough to have a designer and a programmer... each can work independent of the other.
2. "Lookless" view logic. Views are agnostic from the code that runs behind them, enabling the same view logic to be reused across multiple views or have a view easily retooled or replaced. Seperates concerns between "behavior" and "style".
3. No duplicated code to update views. In code-behind you will see a lot of calls to "myLabel.Text = newValue" sprinkled everywhere. With MVVM you can be assured the view is updated appropriately just by setting the underlying property and all view side-effects thereof.
4. Testability. Since your logic is completely agnostic of your view (no "myLabel.Text" references), unit testing is made easy. You can test the behavior of a ViewModel without involving its view. This also enabled test-driven development of view behavior, which is almost impossible using code-behind.

1. 增加视图的“可混合性”（使用 Expression Blend 设计视图的能力）。这使得有幸拥有设计师和程序员的团队的职责分离......每个人都可以独立工作。
2. “Lookless”视图逻辑。视图与运行在它们后面的代码无关，使相同的视图逻辑可以在多个视图中重用，或者可以轻松地重组或替换视图。分离“行为”和“风格”之间的关注点。
3. 没有重复的代码来更新视图。在代码隐藏中，您会看到大量对“myLabel.Text = newValue”的调用随处可见。使用 MVVM，您可以确保仅通过设置底层属性及其所有视图副作用来适当地更新视图。
4. 可测试性。由于您的逻辑与您的视图完全无关（没有“myLabel.Text”引用），因此单元测试变得容易。您可以在不涉及其视图的情况下测试 ViewModel 的行为。这也实现了视图行为的测试驱动开发，这几乎不可能使用代码隐藏。

The other two patterns are really sort of separate in terms of the concerns they address. You can use MVVM with MVP and MVC (most good samples out there do some form of this).

就它们所解决的问题而言，其他两种模式确实有些不同。您可以将 MVVM 与 MVP 和 MVC 结合使用（大多数优秀的示例都采用了某种形式）。

In fact, MVP (w/ a Passive View, rather than a Supervising Controller) is really just a variant of MVVM, in my opinion.

事实上，在我看来，MVP（带有被动视图，而不是监督控制器）实际上只是 MVVM 的一个变体。

回答by Rob Fonseca-Ensor

WPF has better databinding than any other UI framework, which MVVM would be unruly without

WPF 比任何其他 UI 框架具有更好的数据绑定，如果没有 MVVM 将不守规矩

MVVM provides unit testability and excellent view-agnosticism, which make it a good thing to use

MVVM 提供单元可测试性和出色的视图不可知性，这使它成为一件好事

回答by Jeremy Roberts

Baked in support for ICommand and INotifyPropertyChanged are the two biggest benefits. Using MVVM makes it really easy to wire up the commands and plug data into the WPF UI. Things just work.

烘烤支持 ICommand 和 INotifyPropertyChanged 是两个最大的好处。使用 MVVM 可以非常轻松地连接命令并将数据插入 WPF UI。事情只是工作。

回答by Simon Mourier

I personnaly see MVVM not as a benefit, but as an obligation for those who want to use WPF cool features.

我个人认为 MVVM 不是一个好处，而是那些想要使用 WPF 酷特性的人的义务。

WPF is very very heavily built with data binding at the core, to enable separation of UI from Model. But the way data binding is technically done in WPF is somewhat special, as it's tied to classes like:

WPF 以数据绑定为核心构建的非常非常多，以实现 UI 与模型的分离。但是在 WPF 中技术上完成数据绑定的方式有些特殊，因为它与以下类相关联：

• DependencyProperty
• INotifyPropertyChanged
• ObservableCollection

• 依赖属性
• INotifyPropertyChanged
• 可观察集合

Because of this you just can't really write a model the way you want using standard .NET technology. For example, the WPF TreeView is almost impossible to use w/o using data binding and templates. You just can't populate it simply like you would from a generic model in Winforms for example. It mustbe bound to a hierarchical model using ObservableCollection to represent a node's children.

因此，您无法真正使用标准 .NET 技术以您想要的方式编写模型。例如，WPF TreeView 几乎不可能在不使用数据绑定和模板的情况下使用。例如，您不能像从 Winforms 中的通用模型那样简单地填充它。它必须使用 ObservableCollection 绑定到分层模型来表示节点的子节点。

So let's say V represents the XAML code and it's code-behind counterpart (so it's tied to WPF as a technology), and let's say M represents your model (so it's not tied to WPF UI technology in anyway).

因此，假设 V 代表 XAML 代码并且它是代码隐藏对应物（因此它作为一种技术与 WPF 相关联），并且假设 M 代表您的模型（因此它无论如何都与 WPF UI 技术无关）。

Well, you'll never have this working properly under WPF with only these V & M.

好吧，只有这些 V & M，你永远不会在 WPF 下正常工作。

You mustadd something between the two. Something that's WPF-compatible and understands your model. Something that speaks DependencyProperty, ObservableCollection and INotifyPropertyChanged. That's what's called VM.

你必须在两者之间添加一些东西。与 WPF 兼容并理解您的模型的东西。一些涉及 DependencyProperty、ObservableCollection 和 INotifyPropertyChanged 的​​内容。这就是所谓的VM。

As a side note, an alternative to MVVM is to build a V & M (w/o VM plumbing) combination with M being WPF-compatible but still with a reasonable UI independency. Historically, ObservableCollection was in the WindowsBase.dll assembly (that was shipped with WPF), so it really looked weird to bind a generic model to something tied to a UI technology. It's been moved back to System.dll since. Even then, it's sometimes hard to keep a pure VM model w/o tweaking the M specifically for WPF...

作为旁注，MVVM 的替代方案是构建 V & M（无 VM 管道）组合，其中 M 与 WPF 兼容，但仍具有合理的 UI 独立性。从历史上看，ObservableCollection 位于 WindowsBase.dll 程序集中（随 WPF 一起提供），因此将通用模型绑定到与 UI 技术相关的东西看起来确实很奇怪。从那以后，它又被移回了 System.dll。即便如此，有时也很难保持纯 VM 模型而无需专门为 WPF 调整 M ......

回答by danidl

The ability of XAML code to databind, as well as the existance of triggers will break the MVP and MVC Patterns.

XAML 代码数据绑定的能力以及触发器的存在将打破 MVP 和 MVC 模式。