为什么要使用MVVM？

Question

好的，我一直在研究MVVM模式，每次我以前尝试过调查它时，我放弃了很多原因：

1. 不必要的超长编码
2. 编码员没有明显的优势（我办公室没有设计师。目前只有我自己很快成为另一个程序员）
3. 没有很多良好做法的资源/文档！ （或者至少很难找到）
4. 无法想到一个有利的单一场景。

我即将再次放弃它，并认为我会问是否有人回答上述原因。

老实说，我无法看到将其用于单个/合作伙伴编码的优势。即使在具有10个窗口的复杂项目中也是如此。对我来说，DataSet是一个足够好的视图和绑定，就像Brent之后question的答案一样

有人可以展示使用MVVM模式与XAML DataBinding相比节省时间的示例。

此刻我100％的绑定都是在XAML中完成的。因此，我认为虚拟机不仅仅是我需要编写和依赖的额外代码。

修改
在花了一个下午研究MVVM之后，我终于找到了一些让我从这个answer中认识到它的真正好处的东西。

Answer 1

实施模式和遵循最佳实践通常会让人觉得毫无意义，但是当你的老板要求你添加或调整一个功能时，你将成为一个转换。使用MVVM（以及一般的模式），您实际上可以遵循自己的代码，并在最坏的情况下，而不是数周或数月内，在几小时或几天内满足要求。 （这种变化可能只是几行代码，而不是花费数周的时间来试图弄清楚你在尝试添加新功能之前是如何做到的。）

跟进：模式和最佳实践实际上会降低初始开发速度，而这往往对管理层和工程设计都很难。投资回报（以商业术语表示的投资回报率）来自于结构良好的代码，这些代码实际上是可维护的，可扩展的和可扩展的。

例如，如果您正确地遵循MVVM，您应该能够对显示逻辑进行非常大的更改，例如交换整个视图，而不会影响数据和业务逻辑。

关于为模型使用数据集的想法 :(我实际上也因此而陷入困境。）数据集似乎是在应用程序中移动模型数据的完美有效方法。问题在于如何识别数据项。由于您的数据存储在行和列中，因此您必须按列名称或索引执行查找，以及必须过滤特定行。这些逻辑意味着必须在应用程序的布线逻辑中使用魔术字符串和数字。使用类型化数据集可以缓解一些问题但不完全。使用类型化数据集，您将远离MVVM，并在UI和数据源之间实现更紧密的耦合。

Answer 2

它可以帮助您分离GUI和程序逻辑;混合它们会导致很难维护应用程序，尤其是当您的项目随着时间的推移而增长时。

Answer 3

来自here：

  

作为开发者，你为什么要这样做呢   关心Model-View-ViewModel   图案？有很多   这种模式带来的好处   WPF和Silverlight开发。   在你继续之前，问问自己：

     

  
• 您是否需要与设计师共享项目，并拥有   设计工作的灵活性和   发展工作要发生   接近同时？
  
• 您是否需要对解决方案进行彻底的单元测试？
  
• 在内部和外部使用可重复使用的组件对您来说很重要   您组织中的各个项目？
  
• 您是否希望更灵活地更改用户界面   必须重构其中的其他逻辑   代码库？
  

     

如果您对其中任何一个回答“是”   问题，这些只是其中的几个   使用MVVM模型的好处是可以的   带来你的项目。

Answer 4

• 与设计师合作更容易（不是程序员，只是使用Blend的人）
• 代码是可测试的（单元测试）
• 在不弄乱其余代码的情况下更改视图要容易得多
• 在开发UI时，您可以模拟模型并开发界面而无需运行实际服务（仅使用模型中的模拟数据）。然后你只需翻转标志并连接到服务。

Answer 5

MVVM有很多好处，但最重要的是能够测试你的代码（单元测试ViewModels）。

视图和视图模型之间缺乏连接确实有助于松散耦合。重用您编码的组件变得非常容易。

Answer 6

来自Josh Smith's article on MVVM：

  

除了WPF（和   Silverlight 2）创建MVVM的功能   一种自然的结构方式   应用程序，模式也是   很受欢迎，因为ViewModel类是   易于单元测试。当一个   应用程序的交互逻辑存在   在一组ViewModel类中，您可以   轻松编写测试它的代码。在一个   感觉，视图和单元测试都是正确的   两种不同类型的ViewModel   消费者。有一套测试   应用程序的ViewModels提供   自由快速的回归测试，   这有助于降低成本   随着时间的推移保持申请。

对我来说，这是使用MVVM的最重要原因。

之前，我会有控件将视图和视图模型混合在一起。但是视图本质上将鼠标和键盘事件作为输入，并将绘制的像素作为输出。你如何对这样的东西进行单元测试？ MVVM使得这个问题消失了，因为它将untestable视图与可测试的viewmodel分开，并使视图层保持尽可能薄。

Answer 7

我仍然会自己处理这种模式，但我认为它很有价值。目前最大的挑战是该方法仍然很新，因此存在很多混淆，并且该模式的某些关键组件仍然难以实现。我发现了一些帮助我做出更清晰的模式实现的东西：

1. 我大量使用Josh Smith的MVVM Foundation中的RelayCommand。这使得通过命令从View到ViewModel的绑定更加清晰。

2. 我使用AOP来减轻实现INotifyPropertyChanged的痛苦。我目前正在使用Postsharp，但我相信还有其他工具可以做到这一点。如果我没有发现这一点，我现在可能已经放弃了，因为手动实现它的样板代码真的让我烦恼。

3. 我不得不颠倒我对软件实现方式的看法。而不是让一个独裁者阶级告诉他们所有的小兵做什么，而后者又使用他们的仆从，我的软件变得更加松散耦合的服务问题：

   • 这就是我知道该怎么做

   • 这些是我需要完成的事情

当你开始以这种方式构建代码并使用工具来轻松连接依赖项（有很多IoC框架可供选择）时，我发现它可以减轻一些尴尬MVVM，因为您可以减少与将模型注入ViewModel相关联的样板代码，并查找各种View Services（例如显示文件对话框）以供ViewModel使用。

学习这种不同的方法是一项巨大的投资，并且与实施中的任何重大转变一样，当您第一次开始使用它时，生产率会低得多。然而，我开始在隧道尽头看到一些亮点，我相信，一旦我掌握了凌乱的细节，我的应用程序将更清洁，更易于维护。

---

要通过Postsharp解决有关INotifyPropertyChanged的问题，我使用基于示例here的Aspect。我已经为我的用途定制了一些，但这给了你一把关于它的要点。有了这个，我只标记类[NotifyPropertyChanged]，所有公共属性都将在其setter中实现模式（即使它们是自动属性设置器）。对我来说感觉更干净，因为我不再需要担心我是否想花时间让类实现INotifyPropertyChanged。我可以添加属性并完成它。

Answer 8

在此article

中阅读MVVM简介

  

2005年，John Gossman（目前是微软的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又公开模型对象中包含的数据以及特定于视图的其他状态。视图和ViewModel之间的绑定很容易构造，因为ViewModel对象被设置为视图的DataContext。如果ViewModel中的属性值发生更改，则这些新值将通过数据绑定自动传播到视图。当用户单击View中的按钮时，ViewModel上的命令将执行以执行请求的操作。 ViewModel（从不是View）执行对模型数据所做的所有修改。   视图类不知道模型类存在，而ViewModel和模型不知道视图。实际上，该模型完全忽略了ViewModel和视图存在的事实。这是一种非常松散耦合的设计，它可以在很多方面带来好处，你很快就会看到。

这篇文章还解释了为什么要使用这些gui模式：

  

在简单的“Hello，World！”中使用设计模式是不必要的和适得其反的。程序。任何有能力的开发人员都可以一目了然地了解几行代码。然而，随着程序中的特征数量的增加，代码行和移动部件的数量也相应增加。最终，系统的复杂性及其包含的反复出现的问题，鼓励开发人员以更容易理解，讨论，扩展和故障排除的方式组织他们的代码。我们通过将知名名称应用于源代码中的某些实体来减少复杂系统的认知混乱。我们通过考虑其在系统中的功能角色来确定要应用于一段代码的名称。

     

开发人员经常根据设计模式有意地构建代码，而不是让模式有机地出现。这两种方法都没有错，但在本文中，我将研究明确使用MVVM作为WPF应用程序的体系结构的好处。某些类的名称包括MVVM模式中的众所周知的术语，例如，如果该类是视图的抽象，则以“ViewModel”结尾。这种方法有助于避免前面提到的认知混乱。相反，你可以愉快地存在于受控制的混乱状态，这是大多数专业软件开发项目中的自然状态！

Answer 9

我同意使用MVVM通过编写矿石代码更加重视我们的观点， 但是看看所有东西都是孤立的光明面那么如果你是一名设计师，那么你可以设计你的程序，其他人可以为你编写代码，其他人可以为你编写数据库层，看看你将如何维护环境，特别是在大型企业中应用程序，如果你不使用MVVM，那么维护几乎是杀戮.... 我自己在开发ERP解决方案时使用它，现在由于隔离级别，维护非常简单

Answer 10

如果你使用像MVVM这样的模式，你会很高兴，因为其他人发布的所有原因。请记住，您不需要逐字逐句地遵循模式要求，只需确保您的窗口（视图）和逻辑（代码隐藏）之间有很好的分离。

Answer 11

MVVM的好处

1. 降低了复杂性。
2. 设计与开发的隔离。
3. 依赖注入。
4. 主要优势是当您拥有一个Well MVVM结构化Windows Phone应用程序并希望为Windows Metro桌面开发相同时，您只需要专注于设计，因为可以使用相同的视图模型。

希望它有所帮助。

Answer 12

MVVM确实是过多的代码。

那么MVVM有什么好处？

这只是关注点分离而已。您也可以将ViewModel逻辑写入Controller。 ViewModel仅负责进行转换（例如，将对象转换为字符串）。通过使用MVVM，您可以使用更多的面向对象的编程风格。通过将转换逻辑写入Controller，您可以使用更多功能的编程风格。

因此，归结为拥有更多具有更好可读性的代码，或拥有较大Controller文件的更少代码。总之，您不能说必须使用MVVM，因为它比MVC更好，这只是个人喜好。

请弄清楚为什么我提到控制器：MVVM在某处也有控制器代码。我不知道为什么离开C会达成广泛共识。