我最近加入了一个使用 WPF 和 MVVM 构建胖客户端应用程序的新开发项目。我在从 1.1 到 3.5 的各种 .NET 框架和所有主要技术中开发了应用程序； WebForms、MVC 和 WinForms。在我所有的项目中，我都很享受其中的每一分钟，但在这个项目中，我觉得自己很挣扎，因此没有那么享受。当 .NET 3.5 在 2008 年问世时，我非常喜欢学习新的语言功能(LINQ、MVC、Lambda 表达式等)并涉足 WPF，所以请不要认为我反对学习新东西。
但是这个项目的学习曲线似乎真的很陡峭，我觉得在 WPF + 应用程序之上学习 MVVM 有点令人生畏。虽然我参与该项目的时间很短(2 周)，但我真的很喜欢 WPF，但不喜欢 MVVM 模式。我不喜欢 MVVM 模式可能是因为我不太了解它，我觉得我必须编写很多“非最佳实践”代码才能完成在我 WinForms 时代相对简单的事情。
所以我的问题是有没有其他人遇到过类似的情况，你是坚持使用 MVVM 还是转向另一个架构方向？
最佳答案
我从测试版开始就一直在使用 WPF，我永远不会回到 winforms。对我来说，MVVM 是一种哲学，忠实地实现它需要大量的工作和纪律。它鼓励 UI 和交互逻辑之间的完全分离，这意味着没有任何代码隐藏，这意味着可测试的交互逻辑很难用 winforms 实现。
与 gius 相比，我建议您坚持使用纯 WPF 和 MVVM，特别是如果您刚刚开始使用 WPF。 MVVM 和 WPF 有很多需要掌握的地方，增加这些只会减慢你的进度。但那只是我的个人意见。我总是更喜欢分层学习，而不是尝试一次学习所有内容，这样您就可以掌控一切，并且您对应用程序的工作方式有更多了解。
如果您还没有这样做，我强烈建议您阅读有关 MVVM 的 MS 文章:
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
它太棒了，对于编写任何 WPF 代码的我的团队成员来说都是必读的。
我不确定您和您的团队是如何工作的，但您需要问问自己 MVVM 是否适合您。如果单元测试/测试驱动和解耦 UI 是您已经在做的事情或对您很重要，那么 MVVM 绝对是一个不错的选择。如果你的团队乐于在后台编写代码，而你不明白为什么你应该打扰解耦，那么就不要打扰 MVVM，因为你会发现它会减慢你的速度。就我个人而言，后者永远不是我的选择。
如果您对 WPF 或 MVVM 有任何具体问题，请随时与我联系。
关于c# - 学习 WPF 和 MVVM，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2036518/