我最近加入了一个使用WPF和MVVM构建胖客户端应用程序的新开发项目.我已经开发了各种.NET框架中的应用程序,从1.1到3.5以及所有主要技术; WebForms,MVC和WinForms.在我的所有项目中,我都喜欢它的每一分钟,但在这个项目中,我觉得我很挣扎,因此不能享受它.当.NET 3.5在2008年问世时,我非常喜欢学习新的语言功能(LINQ,MVC,Lambda表达式等)并涉足WPF,所以请不要认为我反对学习新东西.
但是这个项目的学习曲线似乎非常陡峭,我觉得在WPF +应用程序之上学习MVVM有点令人生畏.虽然我只是在项目上工作了很短的时间(2周),但我真的很喜欢WPF,但却不喜欢MVVM模式.我不喜欢MVVM模式可能是因为我不太了解它而且我觉得我必须编写很多"非最佳实践"代码才能在WinForms时代做相对简单的事情.
所以我的问题是,是否有其他人遇到类似的情况,你是否坚持使用MVVM或进入另一个架构方向？
小智 11
自测试版以来,我一直在使用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有任何具体问题,请随时与我联系.
| 归档时间： |
|
| 查看次数： |
3817 次 |
| 最近记录： |