学习WPF和MVVM
我最近加入了一个使用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的任何具体问题，请随时与我联系。
我遇到过类似的情况，我决定走的路线是：
我开始学习WPF，并很快遇到了MVVM--它看起来像是一个很好的契合，我坚持下来。 值得指出的是，人们实现MVVM的方式似乎有些不同，其中一个关键是View-first或ViewModel优先。 有些人似乎认为这是福音的一点 - 我没有足够的经验来决定是否应该这样做。 我倾向于View-first（所以View对ViewModel有一个引用，ViewModel对Model有引用而对另一个方向没有引用），但我遇到了另一种方式更容易的场景。
为什么不发表一些你认为非最佳实践的问题。 它也可能帮助其他人摔跤这个话题。
还有一个问题：您是否使用MVVM的特定框架？
链接地址: http://www.djcxy.com/p/64819.html