好的，我一直在研究MVVM模式，但以前每次尝试时都因以下几个原因而放弃:
我即将再次放弃，想问一下是否有人能回答上面的原因。
我真的看不出在单个/合伙编码中使用这个的优势。即使在具有10个窗口的复杂项目中也是如此。对我来说，DataSet是足够好的视图，绑定就像Brent在问题中所述的那样。
能否举一个使用MVVM模式节省时间的例子比较XAML数据绑定。
目前我的100%绑定都是在XAML中完成的。因此，我觉得没有必要使用VM，因为它只是我需要编写并依赖的额外代码。
编辑：
在花了一个下午研究MVVM后，我终于从这个答案中找到了一些让我认识到它真正好处的东西。
对于足够简单的应用程序，每个设计模式都是过度设计。假设您编写一个GUI应用程序，显示一个按钮，按下后显示“Hello world”。在这种情况下，像MVC，MVP，MVVM这样的设计模式增加了很多复杂性，而没有添加任何价值。
通常情况下，仅因某种程度上匹配就引入设计模式是一个不好的决定。设计模式应该用于减少复杂性，可以通过直接减少总体复杂性或者用熟悉的复杂性替代陌生的复杂性来实现。如果设计模式不能以这两种方式之一减少复杂性，则不要使用它。
View和Model，但没有ViewModel。 Model包装了一个csv文件，在启动时读取并在应用程序关闭时保存所有用户对数据所做的更改。 View是一个窗口类，以表格形式显示来自Model的数据，并允许用户编辑数据。 csv内容可能看起来像这样：ID, Name, Price
1, Stick, 5$
2, Big Box, 10$
3, Wheel, 20$
4, Bottle, 3$
View中进行更改，但是我们当前的应用程序使用数据绑定直接显示由我们的Model类提供的数据。由于我们的GUI框架不允许在表格数据绑定到数据源时引入额外的计算列，因此我们需要对View进行重大更改才能使其正常工作，从而使View变得更加复杂。
引入ViewModel
应用程序中没有ViewModel，因为直到现在Model以Csv需要的方式呈现数据，这也是View所需的方式。在中间添加一个ViewModel只会增加无意义的复杂性。但是现在Model不再按照View需要的方式呈现数据，因此我们编写了一个ViewModel。ViewModel以一种使View变得简单的方式投影Model的数据。之前，View类订阅了Model类。现在，新的ViewModel类订阅了Model类，并将Model的数据公开给View——其中包括一个显示欧元价格的额外列。View不再知道Model，它现在只知道ViewModel，从View的角度看，ViewModel与之前的Model相同——除了公开的数据包含一个新的只读列。
新要求：以不同的方式格式化数据
下一个客户请求是，我们不应该将数据显示为表格中的行，而是将每个项目的信息（即行）显示为卡片/框，并在屏幕上以4x5网格的形式显示20个框，每次显示20个框。因为我们保持了 View 的逻辑简单，所以我们只需完全用符合客户要求的新类替换 View。当然还有另一个客户喜欢旧的 View，所以我们现在需要支持两者。由于所有通用业务逻辑已经在 ViewModel 中发生，这并不是什么大问题。因此，我们可以通过将 View 类重命名为 TableView，并编写一个新的 CardView 类来显示以卡片格式显示数据。我们还需要编写一些粘合代码，这可能是启动函数中的一行代码。
新要求：动态汇率
下一位客户的要求是从互联网上获取汇率，而不是使用预定义的汇率。这就是我们重新审视“层”的早期声明的时候了。我们不会改变我们的Model类来提供汇率。相反，我们编写（或查找）一个完全独立的附加类来提供汇率。那个新类成为模型层的一部分，我们的ViewModel将csv-Model和汇率-Model的信息合并在一起，然后呈现给View。对于这个更改，旧的Model类和View类甚至不需要被修改。好吧，我们需要将Model类重命名为CsvModel，并称新类为ExchangeRateModel。ViewModel 类会向现有的 View 类公开某种列表/集合/表，并使用现有的 Model 类中的数据填充其中的大部分内容。根据框架的不同，一个列表项属性/表列可能会用 price * exchangeRate 填充。 - Peter实现模式和遵循最佳实践通常感觉毫无意义，但在数个月后，当您的老板要求您添加或调整某个功能时，您会成为一个信徒。使用MVVM（和一般的设计模式），您将能够有效地遵循自己的代码，并在最坏的情况下在几小时或几天内满足需求，而不是用几周甚至几个月的时间。（这种修改可能仅涉及几行代码，而不需要花费数周时间尝试理解首次编写如何才能新增功能。）
后续： 实际上，遵循设计模式和最佳实践会拖慢初步开发速度，这往往是管理层和工程师都难以接受的。回报（商业术语中的投资回报率）来自于具有良好结构化的代码，这种代码实际上是可维护、可扩展和可伸缩的。
例如，如果您正确遵循了MVVM，您应该能够对显示逻辑进行非常大胆的更改，例如交换整个视图，而不会对数据和业务逻辑造成任何影响。
关于使用数据集作为模型的思考：（我也曾犯过这个错误。）数据集似乎是将模型数据在应用程序中移动的一种完全有效的方法。问题在于，您如何识别数据项。因为您的数据存储在行和列中，您必须按列名称或索引进行查找，并且还必须过滤特定行。这些逻辑意味着在应用程序中使用魔法字符串和数字连接逻辑。使用类型化的数据集可以缓解其中一些问题，但并不能完全解决问题。使用类型化的数据集，您将远离MVVM，并进入UI和数据源之间更紧密的耦合。
它帮助你将GUI和程序逻辑分离；混合它们可能会导致非常难以维护的应用程序，特别是当您的项目随时间增长时。
来自这里：
作为一名开发者，你为什么要关心模型-视图-视图模型（MVVM）模式呢？这种模式对WPF和Silverlight开发都有很多好处。在继续之前，请问自己以下问题：
- 你需要与设计师共享项目，并且希望设计工作和开发工作可以同时进行吗？
- 你需要对解决方案进行彻底的单元测试吗？
- 对于你的组织内部和跨项目使用的可重用组件很重要吗？
- 你希望更灵活地更改用户界面，而不必重构代码库中的其他逻辑吗？
如果你对任何一个问题回答“是”，那么使用MVVM模型可以为你的项目带来诸多好处。
除了WPF（和Silverlight 2）功能使MVVM成为应用程序结构的自然方式外，该模式也很受欢迎，因为ViewModel类易于单元测试。当应用程序的交互逻辑存在一组ViewModel类中时，您可以轻松编写测试代码。从某种意义上说，视图和单元测试只是两种不同类型的ViewModel消费者。拥有一套应用程序ViewModel的测试可提供免费和快速的回归测试，这有助于降低维护应用程序的成本。
对我而言，这是使用MVVM的最重要原因。
以前，我会将视图和视图模型混合在一起。但是，视图本质上具有鼠标和键盘事件作为输入，并具有绘制像素作为输出。如何对此进行单元测试？MVVM通过将不可测试的视图与可测试的视图模型分离，并尽可能保持视图层薄，解决了这个问题。
MVVM有许多好处，但可能最重要的是能够测试您的代码（单元测试ViewModels）。
视图和ViewModel之间缺乏连接确实有助于松耦合。这使得重用您编写的组件变得非常容易。
阅读这篇文章，了解MVVM的介绍。
2005年，微软WPF和Silverlight架构师之一John Gossman在他的博客中发布了模型-视图-视图模型（MVVM）模式。MVVM与Fowler的演示模型相同，因为两种模式都具有View的状态和行为的抽象。Fowler引入Presentation Model作为创建UI平台无关的View抽象的手段，而Gossman则引入MVVM作为利用WPF核心功能简化用户界面创建的标准化方法。从这个意义上讲，我认为MVVM是更一般的PM模式的专业化，为WPF和Silverlight平台量身定制。
..
与MVP中的Presenter不同，ViewModel不需要引用视图。视图绑定到ViewModel上的属性，而ViewModel又公开包含在模型对象和其他特定于视图的状态中的数据。视图和ViewModel之间的绑定很容易构建，因为将ViewModel对象设置为视图的DataContext。如果ViewModel中的属性值更改，这些新值会通过数据绑定自动传播到视图中。当用户在视图中单击按钮时，由ViewModel执行命令来执行请求的操作。ViewModel，而不是View，执行对模型数据所做的所有修改。 视图类不知道模型类的存在，而ViewModel和模型也不知道视图的存在。实际上，模型完全不知道ViewModel和View的存在。这是一种非常松散耦合的设计，从许多方面获得回报，正如您很快就会看到的。如果你采用像MVVM这样的设计模式，出于其他人已经介绍的所有原因，你将从长远来看受益。请记住，你不需要逐字遵循该模式的要求，只需确保在你的窗口（视图）和逻辑（代码后台）之间有良好的分离。