我希望标题能够反映我真正的要求。在我看来，当人们进行基于XAML的开发时，是否使用MVVM甚至不是一个问题，而是一个被理解的事实。来自Winforms和Webforms的背景，我发现我们几乎从未使用MVP（例如）。众所周知，走低MVP路径（除了纯粹主义者）的主要原因是更高水平的单元测试，以及与不同UI共享“视图逻辑”的能力。就后者而言，它在我的项目中从来就不是必需的。如果我们可能有任何用户控件用于此目的。
就单元测试而言，我从未发现有必要测试我的code behind，因为它只是处理UI事件并充当我的业务层的代理（创建实例和绑定）。我可以理解，如果人们绕过业务层并直接在后面的代码中创建他们喜欢的数据访问层的实例，那么就在那里应用业务逻辑，其中MVP将是一个巨大的好处。在我的事业中，我总是用BLL前面的DAL，那么就单元测试而言，真正的“胜利”在哪里呢？
重点是使用MVP从来都不是自动的。我现在正在考虑在一个项目中使用Sliverlight（第一次），如果我不使用MVVM，我觉得我将要犯罪。
我知道有一些MVVM特定的小东西可能在我做“MVP或不MVP”决定之前不是一个考虑因素。我读过Blend支持（我甚至没有Blend），也许还有其他一些重要的方面？但最重要的是，MVVM对于Silverlight来说真的比MVP对Webforms更重要吗？或者我们是否正在进行.NET开发的文艺复兴时期，模式和最佳实践正在成为焦点（有点像Java）。
答案 0 :(得分：2)
我们在MVVM下从Vb.Net winforms转移到C＃和WPF / Silverlight。这绝对是我们的adhock编码的节奏变化。我喜欢能够创建多个视图以使用相同的视图模型。可以轻松地为需要它的客户定制屏幕，而无需进行大量的编程更改。
我发现Stack Overflow中的这些帖子可能会回答您的问题：
Why MVVM and what are it's core benefits?
将MVP与MVVM进行比较，有一些很好的答案。
希望有所帮助。
****另外**
如果您指的是Expression Blend，我在第一次学习xaml时使用了blend。既然我知道我在做什么，我很少使用它，除非我需要做一些复杂的动画或诸如此类的东西。我使用visual studio进行编码，因为从我的经验来看，Blend仍然很麻烦。不要误解我的意思，它是一个很棒的程序，动画效果很好，但它适用于设计师，而不是编码员。
答案 1 :(得分：1)
根据我对WPF和MVVM的有限经验，我的意见是：
MVVM是一种模式，但并不是WPF的最终结果。特别是在MVVM“纯粹主义者”的情况下。即使在WPF中，事件处理程序和代码也有时间和地点。 xaml开发和MVVM的好处是逻辑与设计的分离，但有时，您的逻辑比MVVM允许的更直接地涉及您的设计。
答案 2 :(得分：1)
我想MVVM因为DataBinding的强大功能而被提倡的主要原因。
例如，使用Web表单，您将需要创建自己的接口，框架等...以实现MVP，而在Silverlight / WPF中，数据绑定就在那里，因此无论您是否使用它，它都取决于您。
在我看来，我认为MVVM只是增加了一层可测试的视图逻辑（ViewModel），而不是像MVP模式那样，你的业务逻辑真的可以在演示者本身。
总之，如果它已经存在，易于使用，请使用它......就像你有一辆车，但你仍然可以选择步行10英里到最近的市场，或者你可以开车（大多数会提倡你开车）。
这是我的2美分。