MVC、MVP和MVVM

MVC

MVC设计模式,主要是将逻辑代码,视图层代码,以及数据层代码分离的一种设计模式

• M->Model(模型):是用于处理业务逻辑,例如网络访问,数据库数据读取等。

• V->View(视图):是应用程序中处理数据显示的部分。

• C->Controller(控制器):是用于处理View接收到的任务,然后进行对Model的调用,

mvc.png

代码的处理逻辑:用于在View层对进行了操作,然后View调用Controller中的相应函数.Controller在被调用后接着去调用Model中的对应方法,Model处理好后,直接通知View进行结果的显示.

在MVC中,View要通知Controller,那么在View中需要持有对Controller实例,Model是可以直接修改View的显示的,所有在model需要持有View,或者通过其他方式来通知View的改变

优点

1. 代码之间分工明确,
2. 降低了代码的耦合性,
3. 提高了重用性
4. 增加了可维护性

缺点

1. View与Controller之间耦合性很强,Model层与View之间也存在一定的耦合
2. 针对较简单的功能完全按照规范会显得很繁琐

MVP

MVP设计模式,由于MVC存在的问题,进行改进而来

• M->Model(模型)
• V->View(视图)
• P->Presenter(控制层)

MVP.png

代码的处理逻辑: View层进行了操作后,会通知Presenter层,然后由Presenter调用Model层,然后Model处理后返回给Presenter层,然后Presenter通知View进行改变.

在MVP中,将Model层与View层进行了隔离,所有的都通过Presenter来进行通信.Presenter与具体的View没有直接的关系,都是通过接口来进行交互,所以在一定程度上可以对Presenter进行复用.

优点

1. View层与Model层完全分离,我们可以修改view而不影响model
2. 我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁
3. 单元测试相对简单

缺点

1. 针对较简单的功能完全按照规范会显得很繁琐
2. 在Presenter中如果对view层进行了操作,那么可能会导致presenter层与view层之间耦合性增加
3. 复杂的业务中,可能会导致Presenter层过于臃肿

MVVM

MVVM 相当于MVP的一种更高级的模式,Viewmodel相当于一个中转站,与view层进行双向绑定,与model层通过接口进行数据之间的交互.

MVVM.png

代码的处理逻辑: view与viewmodel通过一定方式进行双向绑定(例如angularjs,Android的databinding等.),viewmodel处理view层的事件,与model层进行数据交互,然后改变自身的数据,由于双向绑定,会直接修改view的显示.这样view层只需要关注自身的逻辑显示,而不用关心数据,同理,数据层只需要关注数据之间的逻辑

• M->Model(模型)
• V->View(视图)
• ViewModel(视图数据)

优点

1. View层与Model层完全分离,viewmodel可以与不同的view进行绑定
2. viewmodel层中拥有部分视图逻辑的话,可以进行重用
3. 可以独立的开发view层以及model层,最后通过viewmodel进行组合
4. 相比较,可测试更强

缺点

1. 代码调试可能会出现问题,有些问题可能因为双向绑定等出现显示不正常等问题
2. 双向绑定会造成view与Viewmodel之间的耦合性增强,造成view的重用有一定的麻烦