好的，我一直在研究MVVM模式，每次以前尝试进行研究时，出于以下原因我都放弃了：
我将再次放弃它，以为我要问是否有人回答了上述原因。
老实说，我看不出将其用于单个/合作伙伴编码的优势。即使在具有十个窗口的复杂项目中。对我来说，DataSet是一个足够好的视图和绑定，就像布伦特在以下问题中的回答一样
有人可以显示一个示例，与XAML DataBinding相比，使用MVVM模式可以节省时间。
目前，我100％的绑定是在XAML中完成的。因此，我不认为VM的意义在于它只是我需要编写和依赖的额外代码。
编辑：
在花了一个下午的时间研究MVVM之后，我终于找到了使我意识到此答案的真正好处的东西。
Answers:
对于足够简单的应用程序，每个设计模式都是多余的。假设您编写了一个GUI应用程序，该应用程序显示一个按钮，当按下该按钮时将显示“ Hello world”。在这种情况下，诸如MVC，MVP，MVVM之类的设计模式都会增加很多复杂性，而不会增加任何价值。
通常，仅仅因为某种程度上合适就引入设计模式总是一个错误的决定。应使用设计模式来降低复杂性，方法是直接降低整体复杂性，或者用熟悉的复杂性代替不熟悉的复杂性。如果设计模式无法通过这两种方式中的任何一种降低复杂性，请不要使用它。
为了解释熟悉和不熟悉的复杂性，请采用以下两个字符序列：
虽然第二个字符序列的长度是第一个字符序列的两倍，但它比第一个字符序列更易于阅读，编写和记忆，所有这些都是因为它比较熟悉。对于代码中熟悉的模式也是如此。
当您认为熟悉程度取决于读者时，此问题会更上一层楼。一些读者会发现“ 3.14159265358979323846264338327950”比上述任何一个密码都更容易记住。有些不会。因此，如果您想使用一种MVVM，请尝试使用一种以您正在使用的特定语言和框架来镜像其最常见形式的镜像。
就是说，让我们通过示例深入探讨MVVM的主题。MVVM指导我们如何在GUI应用程序中的类之间（或在各层之间-稍后再详细介绍）分配职责，目标是拥有少量的类，同时保持每个类的职责数量小且定义明确。
“适当的” MVVM至少假设一个中等复杂的应用程序，该应用程序处理从“某处”获取的数据。它可以从数据库，文件，Web服务或无数其他来源获取数据。
在我们的例子中，我们有2类View和Model，但没有ViewModel。该Model包装了一个CSV文件，它在启动时读取并保存在应用程序关闭时，所有的数据变化作出的用户。的View是一个窗口类，显示从所述数据Model表中的并让用户编辑的数据。csv内容可能看起来像这样：
ID, Name, Price
1, Stick, 5$
2, Big Box, 10$
3, Wheel, 20$
4, Bottle, 3$
新要求：以欧元显示价格
现在，我们被要求对我们的应用程序进行更改。数据由一个二维网格组成，该网格已经具有“价格”列，其中包含美元价格。我们需要添加一个新列，该列显示基于预定义汇率的欧元价格以及美元价格。csv文件的格式不得更改，因为其他应用程序可以使用同一文件，并且这些其他应用程序不受我们的控制。
一个可能的解决方案是将新列简单地添加到Model类中。这不是最好的解决方案，因为Model将所有公开的数据保存到CSV中-我们不希望在CSV中添加新的欧元价格列。因此，对的更改Model将是不平凡的，而且描述Model类所做的事情也将变得更加困难，这就是代码的味道。
我们也可以在中进行更改View，但是当前应用程序使用数据绑定直接显示Model类提供的数据。由于我们的GUI框架不允许我们在表绑定到数据源的数据时在表中引入额外的计算列，因此我们需要对进行重大更改View以使其工作，从而使工作View更加复杂。
介绍ViewModel
ViewModel该应用程序中没有任何内容，因为到目前为止Model，它以Csv所需的确切方式呈现数据，这也是View所需的方式。有一个ViewModel无目的之间就已经增加了复杂性。但是，既然Model不再以所需的方式显示数据View，我们编写一个ViewModel。该ViewModel项目的数据Model以这样的方式使得View可以很简单。之前，View班级已订阅该Model班级。现在，新ViewModel类订阅Model该类，并将Model的数据公开给View-，并有一个额外的列以欧元显示价格。将View不再知道Model，它现在只知道ViewModel，从View外观上看与Model以前相同-除了公开的数据包含一个新的只读列。
新要求：以不同方式格式化数据
客户的下一个要求是我们不应该将数据显示为表格中的行，而应以卡/盒的形式显示每个项目的信息（即行），并在屏幕上以4x5网格显示20个盒，显示20一次装箱。因为我们保持View简单的逻辑，所以我们只View用一个新的类来完全替换它，该类可以满足客户的需求。当然，还有另一个客户喜欢旧的客户View，因此我们现在需要同时支持这两个客户。因为所有常见的业务逻辑都已经碰巧存在，所以ViewModel这不是什么大问题。因此，我们可以通过将View类重命名为TableView并编写一个新的CardView以卡格式显示数据的类。我们还必须编写一些粘合代码，这可能是启动功能中的一个功能。
新要求：动态汇率
下一个客户要求是我们从互联网上获取汇率，而不是使用预定义的汇率。在这一点上，我们将重新讨论我之前有关“层”的声明。我们不会更改Model班级以提供汇率。相反，我们编写（或找到）一个提供汇率的完全独立的附加类。这个新类成为模型层的一部分，我们ViewModel合并了csv-Model和exchange-rate-Model的信息，然后将它们提供给View。对于此更改，甚至不必触摸旧的Model类和View类。好吧，我们确实需要将Model类重命名为，CsvModel然后将其称为new类ExchangeRateModel。
如果我们当时没有引入ViewModel，而是等到现在才这样做，那么现在引入ViewModel的工作量会更多，因为我们需要从ViewandModel和move两者中删除大量功能。的功能ViewModel。
MVVM的主要目的不是将Model和ViewModel中的代码置于单元测试下。MVVM的主要目的是将代码分解为具有少量明确定义的职责的类。由包含少量明确定义职责的类组成的代码的几种好处之一是，将代码置于单元测试中更加容易。更大的好处是代码更易于理解，维护和修改。
ViewModel类向预先存在的View类提供某种类型的List / Collection / Table ，并使用预先存在的Model类中的数据填充其中的大多数。并根据框架，使用填充一个list-item-property / table-column price * exchangeRate。
实施模式和遵循最佳实践通常感觉是毫无意义的追求，但是当老板要求您添加或调整功能几个月后，您将成为转换者。使用MVVM（通常是模式），实际上您将能够遵循自己的代码，并在最坏的几小时或几天内（而不是几周或几个月）满足要求。（此更改可能只是几行代码，而不是花费数周的时间来弄清楚您最初是如何做的，甚至尝试添加新功能。）
跟进：模式和最佳实践实际上会减慢最初的开发速度，这通常给管理和工程界都很难。回报（以商务术语表示的ROI）来自具有实际上可维护，可扩展和可扩展的结构良好的代码。
例如，如果您正确地遵循MVVM，则应该能够对显示逻辑进行非常大的更改，例如换出整个视图，而不会对数据和业务逻辑产生影响。
关于为模型使用数据集的想法：（实际上我也很喜欢。）数据集似乎是在应用程序中移动模型数据的一种完全有效的方法。问题在于如何识别数据项。因为您的数据存储在行和列中，所以您必须按列名或索引执行查找，还必须针对特定行进行过滤。这些逻辑位意味着您必须在应用程序的布线逻辑中使用魔术字符串和数字。使用类型化的数据集可以缓解某些问题，但不能完全缓解。使用类型化的数据集，您将远离MVVM，而进入UI和数据源之间的紧密耦合。
从这里：
作为开发人员，您为什么还要关心Model-View-ViewModel模式？这种模式为WPF和Silverlight开发带来许多好处。在继续之前，请问自己：
- 您是否需要与设计师共享项目，并具有使设计工作和开发工作几乎同时进行的灵活性？
- 您是否需要对解决方案进行彻底的单元测试？
- 在组织中的项目内部和之间具有可重用的组件对您来说重要吗？
- 您是否需要更大的灵活性来更改用户界面，而不必重构代码库中的其他逻辑？
如果您对这些问题中的任何一个回答“是”，那么这些只是使用MVVM模型可以为您的项目带来的一些好处。
除了WPF（和Silverlight 2）功能使MVVM成为构建应用程序的自然方式之外，该模式也很流行，因为ViewModel类易于进行单元测试。当应用程序的交互逻辑位于一组ViewModel类中时，您可以轻松编写测试它的代码。从某种意义上说，视图和单元测试只是两种不同类型的ViewModel使用者。拥有针对应用程序的ViewModels的测试套件可提供免费和快速的回归测试，这有助于降低随着时间的推移维护应用程序的成本。
对我来说，这是使用MVVM的最重要原因。
以前，我有将视图和视图模型混在一起的控件。但是视图本质上将鼠标和键盘事件作为输入，并将绘制的像素作为输出。您如何对这样的内容进行单元测试？MVVM消除了无法测试的视图与可测试的视图模型的距离，并使该视图层尽可能地薄，从而解决了该问题。
关于MVVM有很多好处，但是也许最重要的是测试代码的能力（对ViewModels进行单元测试）。
视图和视图模型之间缺乏连接确实也有助于松散耦合。重用您编写的组件变得非常容易。
阅读本文中的MVVM简介
2005年，John Gossman（目前是Microsoft的WPF和Silverlight架构师之一）在他的博客中公开了Model-View-ViewModel（MVVM）模式。MVVM与Fowler的Presentation Model相同，因为这两种模式都具有View的抽象，其中包含View的状态和行为。Fowler引入了Presentation Model作为创建独立于UI平台的View抽象的一种方式，而Gossman引入了MVVM作为利用WPF核心功能简化用户界面创建的标准化方法。从这个意义上讲，我认为MVVM是针对WPF和Silverlight平台量身定制的更为通用的PM模式的专业化。
..
与MVP中的Presenter不同，ViewModel不需要引用视图。视图绑定到ViewModel的属性，而ViewModel的属性又公开了模型对象中包含的数据以及该视图特定的其他状态。view和ViewModel之间的绑定很容易构造，因为ViewModel对象被设置为视图的DataContext。如果ViewModel中的属性值发生更改，这些新值将通过数据绑定自动传播到视图。当用户单击视图中的按钮时，将执行ViewModel上的命令以执行请求的操作。ViewModel（而不是View）执行对模型数据所做的所有修改。视图类不知道模型类存在，而ViewModel和模型不知道视图。实际上，该模型完全忽略了ViewModel和视图的存在。
文章还解释了为什么使用这些gui模式：
在简单的“ Hello，World！”中使用设计模式是不必要且适得其反的。程序。任何有能力的开发人员一眼就能理解几行代码。但是，随着程序中功能数量的增加，代码行和移动部件的数量也相应增加。最终，系统的复杂性及其所包含的反复出现的问题，促使开发人员以一种易于理解，讨论，扩展和排除故障的方式来组织代码。通过将众所周知的名称应用于源代码中的某些实体，我们减少了复杂系统的认知混乱。我们通过考虑代码在系统中的功能角色来确定要应用于一段代码的名称。
开发人员经常有意根据设计模式来构造代码，而不是让这些模式有机地出现。两种方法都没有错，但是在本文中，我研究了显式使用MVVM作为WPF应用程序体系结构的好处。某些类的名称包含MVVM模式中的知名术语，例如，如果该类是视图的抽象，则以“ ViewModel”结尾。这种方法有助于避免前面提到的认知混乱。相反，您可以快乐地处于受控混乱的状态，这是大多数专业软件开发项目中的自然状态！
我本人仍将继续熟悉该模式，但我确实认为它很有价值。当前最大的挑战是该方法仍然很新，因此存在很多混乱，并且该模式的某些关键组件仍然难以实现。我发现了一些有助于我更清晰地实现该模式的东西：
我大量使用了Josh Smith的MVVM Foundation的RelayCommand 。这使得通过命令从View到ViewModel的绑定更加简洁。
我使用AOP来减轻实现INotifyPropertyChanged的痛苦。我目前正在使用Postsharp，尽管我相信还有其他工具可以做到这一点。如果我还没有发现这一点，那么我现在可能会放弃，因为手动实现它的样板代码确实让我很烦。
我不得不将我的方法转换为软件实现方式。我的软件不再是一个独裁者类，该独裁者类告诉其所有奴才做什么，反过来又使用他们的奴才，而我的软件则更多地是由松散耦合的服务决定的：
这就是我所知道的
这些是我需要做的事情
当您开始以这种方式构建代码并使用易于连接依赖项的工具（有多种IoC框架可供选择）时，我发现它减轻了MVVM的某些尴尬，例如您可以减少与将模型注入ViewModel并查找供ViewModel使用的各种View Services（例如显示文件对话框）相关的样板代码。
学习这种不同的方法是一笔巨大的投资，并且与实施中的任何重大变化一样，当您首次开始使用它时，生产率会大大降低。但是，我开始在隧道尽头看到一些曙光，我相信，一旦掌握了凌乱的细节，我的应用程序将变得更干净，更可维护。
为了通过Postsharp解决有关INotifyPropertyChanged的问题，我基于此处的示例使用了Aspect 。我对它进行了一些自定义，以供使用，但这可以使您明白要点。这样，我只需标记类[NotifyPropertyChanged]，所有公共属性都将在其设置器中实现模式（即使它们是自动属性设置器）。对我来说，这很干净，因为我不必担心是否要花时间使该类实现INotifyPropertyChanged。我可以添加属性并完成它。
MVVM的好处
希望能帮助到你。