MVFM框架—-概述

这一章节主要阐述下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的新特性揉合进去，以应对客户日益复杂的需求变化。其中核心技术则是依赖数据绑定。

MVVM的优点在于：

• 1. 低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的”View”上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
• 2. 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
• 3. 独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用Expression Blend可以很容易设计界面并生成xaml代码。
• 4. 可测试。界面素来是比较难于测试的，而现在测试可以针对ViewModel来写。

MVVM的缺点在于：

• 1. 解耦不彻底。由于ViewModel需要根据View量身定制，虽然不需要直接渲染界面，但不可避免的要涉及一些界面上的状态信息。当View需要更改时，ViewModel也需要更改。仅当View上一些控件位置的移动，样式更改时才不需要更改ViewModel，一旦有功能和业务逻辑有变动时，ViewModel也要做相应的变动。
• 2. ViewModel逻辑复用有限。当某个界面上的功能较多时，ViewModel也很庞大。而有时为了重用和适用于多个View,ViewModel中还要涉及一些其他View的逻辑。

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】