WPF中MVVM模式原理分析与实践

核心提示： 但与MVC,MVP所不同的是,MVVM的引入不仅仅是技术上的原因(解除耦合应对变化等老生常谈),另外一个很大原因是:软件团队开发方式的改变.如果你做过一段时间的WPF项目开发的话,你可能会有比较明显的感觉:在View层打造上,如何分配程序员和美工的工作.在继续阅读之前,大家可以看看我以前的

但与MVC,MVP所不同的是,MVVM的引入不仅仅是技术上的原因(解除耦合应对变化等老生常谈),另外一个很大原因是:软件团队开发方式的改变.如果你做过一段时间的WPF项目开发的话,你可能会有比较明显的感觉:在View层打造上,如何分配程序员和美工的工作.在继续阅读之前,大家可以看看我以前的一篇文章"在UI Designer与Developer之间". 以前我们团队采用的便是"集成模式", 我便兼职了其中的"Integrator"角色.这还不错.但说实在的,这仅仅是一个在特殊情况下不得已而为之的暂时方案,所以我们付出了很大的努力开始转向"收割模式"了,要转向这个模式,至少需要两个基本条件:

(1)你拥有能够熟练运用Blend等工具能为程序员输出XAML的美工, 他专注于纯粹的UI/UE, 另外他还必须具有一定的"程序员"思维.以便输出的东西能很好地作为程序的一部分而运转起来,而不是仅仅"看上去"是那样的。

(2)你需要能够脱离View层但仍能编写出高质量代码的程序员。

幸运的是, 我们在努力创造条件1,并取得了很好的效果.(你可以招一个具有Flash脚本编写经验的并且有极大的学习热情的美工人员, 并对他进行Blend的相关培训). 而MVVM模式为我们实现第二个条件提供了极大的便利. 为什么MVC/MVP模式不行而MVVM可以呢? 很简单, 在MVC和MVP模式中, View层都具有很多代码逻辑, 开发View层的是程序员, 虽然UI/UE团队会做很多工作, 但这个层的"实现者"仍然是程序员. 在以前的开发中,其工作得很好, 而在WPF开发中程序员对View层的展现显得力不从心了,美工(指符合上面条件1的美工)虽然很擅长, 但他会说"可惜我不会程序".于是, 我们需要一种方式将View层的代码逻辑抽取出来,并View层很纯粹以便完全让美工去打造它.相应地, 需要将View层的相应逻辑抽取到一个代码层上,以便让程序员专注在这里。