我对MVVM的看法很复杂。似乎我需要编写如此多的代码来获得最有效的补救措施。我想念事件（命令是如此痛苦），绑定一切导致调试噩梦，我错过了对视图的引用！
我只是想知道你对MVVM的感受与背后的普通旧代码。你更喜欢什么和/或你通常使用或建议使用什么？
由于
答案 0 :(得分：7)
我绝对是少数人，但我倾向于同意@Shnitzel。 MVVM以及与之相辅相成的绑定是很好的想法，但它们很难被当前的MS工具所服务。除了最简单的绑定之外的所有语法都非常难以正确使用，并且由于WPF和Silverlight无声地吞下所有错误这一事实变得更加困难。 （是的，一些错误出现在调试窗口中，但还不够，而且没有足够的细节。）你可以使用hacks来编写调试值转换器，但事实仍然是工具集仍然很不成熟。 （然后是我的标准投诉，数据绑定不是强类型的，这意味着工具无法为您捕获错误。）
当他们坚持可测试性时，我听到了所有人，而且我是自动化测试的忠实粉丝。但至少在目前我们的工具状态下，MVVM的可测试性得到了很大提升。
考虑这种情况：你有一个包含50多个表单/页面的大型应用程序，而你刚刚对模型和ViewModel进行了重大的重构。在此过程中，您重命名了一堆类和属性等。现在找到XAML中您需要更改的每个位置以反映新的类和属性名称。可测试性如此之高，嗯？ IDE不仅不会捕获您的绑定错误，编译器也不会捕获它们，最重要的是，应用程序甚至不会在运行时抛出错误。您必须让测试人员在整个应用程序中运行，并确保所有绑定仍在执行您希望他们执行的操作。 Ugggh。丑陋而痛苦。至少当我以老式的方式做事时，编译器会告诉我什么时候拼写错误。
回到我的山洞，避免吊索和箭头快速前进......
[编辑12/10/2010 - MS最近宣布SL5将具备debug data bindings的能力，包括在其上设置断点的能力，因此您可以看到正在发生的事情。这是朝着正确方向迈出的一大步。它仍然没有解决我认为的基本问题，数据绑定没有编译时类型检查，但它提高了工具集的实用性。]
答案 1 :(得分：5)
人们提到了测试，这是一个好点。 我认为另一点是可重用性，将相同的viewmodel绑定到不同的视图。例如，您可能对某些用户有简化的视图，对其他用户有更高级的视图。
我看到人们提到如何处理事件是一种痛苦等等。有MVVM框架可以处理这个问题。在我看来，将事件处理程序挂钩到代码隐藏的视图模型和调用Viewmlol上的方法也是可以接受的。它肯定比不使用MVVM更好，因为人们可能很难连接事件。
另一个巨大的优势在于MVVM的本质，GUI和业务逻辑的分离。如果你与设计师合作，他们都在XAML世界，谈论渐变，边框，阴影和什么不是。在您的同时，程序员可以通过单元测试快速编写ViewModel代码。因此，当设计师准备好原型时，只需要连接命令和绑定即可。简单的piecy GUI ready =）
答案 2 :(得分：5)
迭代开发会回来，标记我的话。一旦TDD的真实成本与某些功能的生产相比变得更加明显，就需要尽快实现。
答案 3 :(得分：3)
现在，有些人使用MVVM并且很好。 有些人不是因为他们正在解除大部分开发任务，而不是与设计师，测试人员等一些大项目。 但是，我一直都在这两个方面。无论如何，都有人跳过任何模式并且必须实现它。 即使是用于管理一些小数据的小型应用程序也正在MVVM中开发。它们将被安排和计划数周，即使其中一些程序可能在几天内被黑客攻击，但必须满足模式和测试等。 老实说：许多开发人员通过实践来学习，其中一些模式极其压倒性，因为它们结合了如此多的模式和抽象的编程技术。
答案 4 :(得分：2)
事实是，许多人不使用单元测试。然而，仍然有充分的理由使用MVVM。我想指出，这会使业务逻辑脱离UI。此外，如果您有类似的视图，则可以对它们使用相同的视图模型。
我也很喜欢我可以对用户界面做出巨大的改变，而不必触及我的逻辑。或者，我可以轻松添加更多逻辑而无需触摸我的UI。例如，我已经从列表更改为组合框，而不必触摸代码。
至于指挥，长期以来对我来说是一个难点。然后我在MVVM Light中发现了RelayCommand。有了它，设置一个方法来触发命令非常简单。就个人而言，我几乎从未在命令中使用参数选项。我更喜欢只在viewmodel中使用state。
答案 5 :(得分：1)
类似MVVM的方法的有用性随着应用程序的范围和复杂性而扩展。一方面是“不是很复杂，不是很有用”，另一方面是“建立很多人年，没有像MVVM这样的东西就不可能”。
可测试性与此相辅相成 - 应用程序足够小＆amp;很简单，MVVM感觉过于顶级也是如此之小和简单，以至于真正的单元测试覆盖范围是荒谬的。然而，现实世界通常非常复杂，这意味着真实世界的应用程序确实需要单元测试来保持质量，并且他们确实需要MVVM可测试和可管理。任何认为自己没有它们的人都会在很少需要的情况下燃烧大量的能量;或者更糟糕的是，让严重的质量问题被其他东西掩盖。
答案 6 :(得分：0)
来自Josh Smith's article on MVVM：
除了WPF（和 Silverlight 2）创建MVVM的功能 一种自然的结构方式 应用程序，模式也是 很受欢迎，因为ViewModel类是 易于单元测试。当一个 应用程序的交互逻辑存在 在一组ViewModel类中，您可以 轻松编写测试它的代码。在一个 感觉，视图和单元测试都是正确的 两种不同类型的ViewModel 消费者。有一套测试 应用程序的ViewModels提供 自由快速的回归测试， 这有助于降低成本 随着时间的推移保持申请。
对我来说，这是使用MVVM的最重要原因。
之前，我会有控件将视图和视图模型混合在一起。但是视图本质上将鼠标和键盘事件作为输入，并将绘制的像素作为输出。你如何进行单元测试或集成测试呢？ MVVM使得这个问题消失了，因为它将untestable视图与可测试的viewmodel分开，并使视图层保持尽可能薄。
答案 7 :(得分：0)
MVVM有其难点 - 就像命令所需的所有样板代码一样，搞乱绑定语法以及需要关闭表单的令人难以置信的愚蠢黑客。
- 但是 -
这都是由于缺乏一个好的框架 - this video对我来说是个大开眼界，如果你选择了正确的框架它可以自动处理所有讨厌的部分（如果你不能找到一个好的框架编写自己的迷你框架，解决你的痛点比处理“裸”MVVM更容易。
看看那个视频，看看如何用一个好的小框架编写MVVM应用程序，用的代码少于其他代码。