这一章节主要阐述下MVFM框架的由来和概念。
首先说说MVVM框架的由来。MVVM是MVP(Model-View-Presenter)模式与WPF结合的应用方式时发展演变过来的,而MVP则是由经典的模式MVC演变而来。MVP与MVC它们的基本思想有相通的地方:Controller/Presenter负责逻辑的处理,Model提供数据,View负责显示。MVP与MVC有着一个重大的区别:在MVP中View并不直接使用Model,它们之间的通信是通过Presenter (MVC中的Controller)来进行的,所有的交互都发生在Presenter内部,而在MVC中View会从直接Model中读取数据而不是通过 Controller。
由于MVC中的View可以直接访问Model,则不可避免的导致一些业务逻辑在View里实现。这样的弊端有2个,一是View中的逻辑不可复用,二是由需求改动的时候修改View比较困难。
在MVP里,Presenter完全把Model和View进行了分离,主要的程序逻辑在Presenter里实现。而且,Presenter与具体的View是没有直接关联的,而是通过定义好的接口进行交互,从而使得在变更View时候可以保持Presenter的不变,即逻辑重用。MVC是系统级架构的,而MVP是用在某个特定页面上的,也就是说MVP的灵活性要远远大于MVC,实现起来也极为简单。但MVP的缺点也很明显,就是由于对视图的渲染放在了Presenter中,所以视图和Presenter的交互会过于频繁,一旦View需要变更则Presenter也需要变更了。
MVVM(Model-View-ViewModel)框架的由来便是MVP模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性揉合进去,以应对客户日益复杂的需求变化。其中核心技术则是依赖数据绑定。
MVFM是Model-View-FunctionModel的简写。MVFM与MVVM最大的区别在于,业务逻辑处理根据功能按最小粒度划分,即FunctionModel.
在程序编写过程中,一个界面上往往涉及多个功能,特别是像Win8和Wp的应用中,横向滑动的交互方式导致主界面上往往即有数据列表信息也有用户信息等多个功能块。在MVFM中将数据逻辑单独封装到一个FunctionModel中,用户相关逻辑封装到另一个单独的FunctionModel中。则界面上的业务逻辑由不同的FunctionModel组成,View与FunctionModel的通讯由Command,Binding,Behavior和Trigger进行。相对于MVVM的单ViewModel依赖,这样的灵活性和复用性更高,单纯在XAML页面我们就可以完成大部分的逻辑处理。
再稍后的博客中我将会放出MVFM源码,分为Wp8和Win8两个版本,并提供Demo加深理解。
【原文:http://blog.csdn.net/chengwd2008/article/details/8600707】