我最近加入了一个使用WPF和MVVM构建厚客户端应用程序的新开发项目。我曾经在各种.NET框架中开发过应用程序，从1.1到3.5以及所有主要技术；WebForms、MVC和WinForms。在我的所有项目中，我都非常喜欢这个过程，但是在这个项目中，我感到自己有些吃力，因此没有那么享受它。当.NET 3.5在2008年推出时，我非常喜欢学习新的语言特性（LINQ、MVC、Lambda表达式等），并涉猎了一下WPF，所以请不要认为我反对学习新东西。
但是，在这个项目上的学习曲线似乎非常陡峭，我觉得在学习WPF的同时还要学习MVVM对我来说有点棘手。虽然我只参与了项目两周，但我真的很喜欢WPF，但对MVVM模式却有些不喜欢。我对MVVM模式的不喜欢可能是因为我真的不太理解它，而且我觉得我必须编写大量“非最佳实践”的代码，才能完成在WinForms时相对简单的任务。
所以我的问题是，是否有其他人面临过类似的情况，你们是坚持使用MVVM还是采取了其他架构方向呢？
我从beta版开始就一直在使用WPF，我再也不想回到winforms了。对我来说MVVM是一种哲学，需要很多工作和纪律性才能忠实地实现它。它鼓励完全将UI与交互逻辑分离，这意味着绝对没有任何代码后台，这意味着可以进行可测试的交互逻辑，而winforms很难做到这一点。
与gius相比，如果您刚开始使用WPF，我建议您坚持使用简单的WPF和MVVM。MVVM和WPF有很多需要理解的内容，加上其他东西只会减缓您的进度。但这只是我的观点。我总是更喜欢逐层学习，而不是试图一次性学习所有内容，这样你就可以掌控并更了解应用程序的工作方式。
如果您还没有这样做，我强烈建议您阅读MS关于MVVM 的文章：
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
这篇文章非常棒，对于我的团队成员编写任何WPF代码都是必读的。
我不确定您和您的团队是如何工作的，但您需要问自己MVVM是否适合您。如果单元测试/测试驱动和解耦UI是您已经在做或对您很重要的内容，那么MVVM绝对是一个好的选择。如果您的团队习惯于编写代码后台而且您不知道为什么应该烦恼解耦，那么不要烦恼MVVM，因为您会发现它会减慢您的速度。对我个人而言，后者从来不是一个选项。
如果您有任何关于WPF或MVVM的具体问题，请随时与我联系。
我曾经遇到过类似的情况，我决定采取以下路线：
在使用MVVM之前，我在ASP.NET MVC框架中使用了MVC。那里的模型-视图-控制器架构非常明显，因此它帮助我改变了从标准ASP.NET和WinForms的态度。
MVVM有点难以理解，但是一旦你意识到WPF与Web不同（您作为用户对视图而不是控制器做出响应），从MVC转移到MVVM就有意义了。 我建议阅读Caliburn项目主页上关于MVVM的文章（左栏，第3部分学习MVVM）-这对我帮助很大。
关于WPF（Silverlight）应用程序，我强烈建议从PRISM（Composite WPF）和/或Caliburn开始构建应用程序-尽管从一开始可能会令人困惑，但仍然比使用原始WPF更好（说的是它们强迫您使用的实践）。但可以肯定的是，一旦完成了第一个WPF应用程序，您将想要从头开始重写它。但这就是学习新技术的方式。
MVVM只是一种设计模式。除非您熟悉WPF，否则不需要使用它。如果您正在学习WPF，建议您先完成书籍的学习，然后再了解MVVM。如果您同时学习两者，您可能会尝试在每个简单的WPF应用程序中实现MVVM，或者无法理解MVVM使用的某些WPF功能。
P.S：当我自己面临这个问题时，我得出了这个结论。我仍然不明白ViewModel如何在不知道它的情况下创建一个新的View。
WPF 学习曲线陡峭，MVVM 也是如此。这就解释了你的感受：同时掌握 XAML 和 MVVM 并尝试制作真实世界应用程序是一项艰巨的任务。
我已经培训过像你这样的 .NET 开发人员，并帮助他们快速掌握学习曲线。然后将这些培训内容打包成一本快速阅读的书籍，您可以在这里获取：
它也可在亚马逊和主要图书网站上获得。
如果听起来像自我推销，我很抱歉，但我真的相信这本书完全适合您的个人资料。
