我正在努力为自己做好准备迎接问题：
“为什么我们不能在后面的代码中实现演示模型？”
事实上，我参与了一个项目，我们使用了一个在后面的代码中实现的Presentation Model。它运作得相当好，我们甚至可以对它进行单元测试。是的，你在单元测试中依赖于WPF ......但它确实有效！
然后，使用代码的主要缺点是什么？
我更喜欢独立ViewModel（MVVM）的想法，但目前我觉得无法向客户证明这一点。
答案 0 :(得分：1)
您回答了问题的第一部分，必须在单元测试期间引导wpf应用程序。另一个是可移植性，您是否希望能够将不同的视图实现附加到同一个表示模型。 （我知道的很弱但是你得到的全部）
也是技能组合的分离，只有知道xaml的开发人员才会参与视图的实际创建。允许你利用不知道wpf的内部人才。
答案 1 :(得分：1)
直截了当的回答是principle of separation of concerns。当然，有人可能会争辩说，通过将表示模型放在代码隐藏中，它与视图（XAML）是分开的，但我不同意这一点。代码隐藏可以“查看”视图的所有内部细节，因为它 视图。 xaml和代码隐藏都被编译成一个类，成为View。它们根本不是分开的。
有很多例子你需要进入代码隐藏来做与视图相关的事情，比如在Xaml中无法指定的控件之间的交互。完成后，您现在可以将视图逻辑与表示逻辑混合在一起。
ViewModel的概念非常强大。 ViewModels可以相互“交谈”，而不会让“视图”相互“交谈”，甚至没有ViewModels“知道”有关视图的任何信息。
答案 2 :(得分：1)
检查这两个视频以获得一些想法。这两个视频都展示了开发应用程序从代码背后的所有内容开始，然后它们重构为MVVM模式。
此外，请参阅此SO问题以获取更多链接：MVVM: Tutorial from start to finish?
答案 3 :(得分：1)
使用 ViewModel-First 方法时，它会成为一个缺点。在主应用程序中，您实例化ViewModel对象图，将其分配给根视图datacontext，然后让视图根据ViewModel通知呈现其相关子对象。
为什么这是一个缺点？事实上你可以使用你的代码，但你最终会得到一个tricks的bounch，有时应该forgot your application security。 但实际上这种方法是理想的方法，你的viewmodel完全无知，甚至你可以通过程序首先逆转你的开发过程 - 后者。 （开玩笑）
另一方面，如果你使用 View-First 方法，则没有任何缺点，因为viewmodel就位于它上面。因为如果你需要一些棘手的东西，控制仍然在视图中使用密码框然后就像微软给我们的命运一样自然地做到这一点..
希望有所帮助。