我绝对是少数人，但我倾向于同意@Shnitzel。 MVVM以及与之相辅相成的绑定是很好的想法，但它们很难被当前的MS工具所服务。 除了最简单的绑定之外的所有语法都很难正确，并且由于WPF和Silverlight无声地吞下所有错误而变得更加困难。 （是的，一些错误出现在调试窗口中，但是没有足够的错误，并且没有足够的细节。）你可以使用hacks来编写调试值转换器，但事实仍然是工具集仍然相当不成熟。 （然后是我的标准投诉，数据绑定不是强类型的，这意味着工具无法为您捕获错误。）

当他们坚持可测试性时我听到了所有人，而且我是自动化测试的忠实粉丝。 但至少在目前我们的工具状态下，MVVM的可测试性得到了提升，价格非常高。

考虑一下这种情况：你有一个包含50多个表单/页面的大型应用程序，而你刚刚对模型和ViewModel进行了重大的重构。 在此过程中，您重命名了一堆类和属性等。现在找到XAML中您需要更改的每个位置以反映新的类和属性名称。 可测试性如此之高，嗯？ IDE不仅不会捕获您的绑定错误，编译器也不会捕获它们，最重要的是，应用程序甚至不会在运行时抛出错误。 您必须让测试人员在整个应用程序中运行，并确保所有绑定仍在执行您希望他们执行的操作。 Ugggh。 丑陋而痛苦。 至少当我以老式的方式做事时，编译器会告诉我什么时候拼写错误的东西。

回到我的洞穴，以避免吊索和箭头迅速前进…

[编辑12/10/2010 – MS最近宣布SL5将具有调试数据绑定的能力，包括在其上设置断点的能力，因此您可以看到正在发生的事情。 这是朝着正确方向迈出的一大步。 它仍然没有解决我认为的基本问题，数据绑定没有编译时类型检查，但它提高了工具集的实用性。

人们提到了测试，这是一个好点。 我认为另一点是可重用性，将相同的viewmodel绑定到不同的视图。 例如，您可能对某些用户有简化的视图，而对其他用户有更高级的视图。

我看到人们提到如何处理事件是一种痛苦等等。 有MVVM框架可以处理这个问题。 在我看来，也可以将事件处理程序挂钩到代码隐藏，并在代码隐藏的viewmodel上调用方法。 它肯定比不使用MVVM更好，因为人们可能很难连接事件。

另一个巨大的优势在于MVVM的本质，GUI和业务逻辑的分离。 如果你与设计师合作，他们都在XAML世界，谈论渐变，边框，阴影和什么不是。 在您的帮助下，程序员可以通过unit testing快速编写ViewModel代码。 因此，当设计师准备好原型时，只需要连接命令和绑定即可。 简单的piecy GUI ready =）

整个问题是，恕我直言，一堆超级科技的营销炒作，并且从长远来看除了推动发展到开发成本可以承担生产力损失的负担之外，没有任何目的…即，关闭 – 岸。 创建一个可以完成任何工作的functionUI是一种疯狂的SLOW。 好像所有应用都是简单的内容页面，购物车或数据网格。 太糟糕了。 所以 – 如果一个有几个错误的应用程序在几个发布周期中被淘汰是如此糟糕，我们只需将其交换为一个没有人能够理解端到端整体情况的系统。 .. 为了什么？ 可测试性？ 真是一堆完整的垃圾。 好像错误和修复的日子是什么，消失了？ 雅，对…我的测试说2 + 2 = 4，因此我的应用程序没有错误。 对。

迭代开发会回来，标记我的话。 一旦TDD的真实成本与SOMEfunction的生产相比变得更加明显，就需要尽快实现。

现在，有些人使用MVVM并且很好用。 有些人不是因为他们正在解除大部分开发任务，而不是与设计师，测试人员等人进行过一些大项目。 但是，我一直都在这两个方面并且已经看过两种方式。 无论如何，都有人跳过任何模式并且必须实现它。 即使是用于管理一些小数据的小型应用程序也正在MVVM中开发。 它们将被安排和计划数周，即使其中一些程序可能在几天内被黑客攻击，但必须满足模式和测试等。 老实说：许多开发人员通过实践来学习，其中一些模式极其压倒性，因为它们结合了如此多的模式和抽象的编程技术。

事实是很多人不使用unit testing。 然而，仍然有充分的理由使用MVVM。 我想指出这会使业务逻辑脱离UI。 此外，如果您有类似的视图，则可以对它们使用相同的视图模型。

我也喜欢我可以对UI做出巨大的改变而不必触及我的逻辑。 或者，我可以轻松添加更多逻辑而无需触摸我的UI。 例如，我已从列表更改为combobox，而不必触摸代码。

至于指挥，长期以来对我来说是一个难点。 然后我在MVVM Light中发现了RelayCommand。 有了它，设置一个方法来触发命令非常简单。 就个人而言，我几乎从不在命令中使用参数选项。 我更喜欢只使用viewmodel中的state。

类似MVVM的方法的有用性随着应用程序的范围和复杂性而扩展。 一方面是“不是很复杂，不是很有用”，而另一方面是“建立很多人年，没有像MVVM那样的东西”。

可测试性与此相辅相成 – 应用程序足够小且足够简单，以至于MVVM感觉过于顶级也非常小而且简单，以至于真正的unit testing覆盖率非常低。 然而，现实世界通常非常复杂，这意味着现实世界的应用程序确实需要unit testing来保持质量，他们确实需要MVVM可测试和可管理。 任何认为自己没有它们的人都会在很少需要的时候燃烧大量的能量; 或者更糟糕的是，让严重的质量问题被其他东西掩盖。

来自Josh Smith关于MVVM的文章 ：

除了使MVVM成为构建应用程序的自然方式的WPF（和Silverlight 2）function之外，该模式也很受欢迎，因为ViewModel类很容易进行unit testing。 当应用程序的交互逻辑存在于一组ViewModel类中时，您可以轻松编写测试它的代码。 从某种意义上说，Views和unit testing只是两种不同类型的ViewModel消费者。 对应用程序的ViewModels进行一系列测试可提供免费且快速的回归测试，这有助于降低维护应用程序的成本。

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

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

MVVM有它的难点 – 就像命令所需的所有样板代码一样，搞乱绑定语法和非常愚蠢的黑客需要关闭表单。

– 但是 –

这都是由于缺乏一个好的框架 – 这个video对我来说是一个大开眼界，如果你选择正确的框架，它可以自动处理所有讨厌的部分（如果你找不到一个好的框架写你的自己的迷你框架解决你的痛点比处理“裸”MVVM更容易。

只要看看那个video，看看如何使用一个好的小框架，你可以用比其他代码更少的代码编写MVVM应用程序。

上述就是C#学习教程：WPF / Silverlight程序员：MVVM是否过度杀伤？分享的全部内容，如果对大家有所用处且需要了解更多关于C#学习教程，希望大家多多关注—计算机技术网(www.ctvol.com)!