MVC/MVP/MVVM

MVC

1,M:业务逻辑处理:数据库操作,网络操作,耗时任务(各种java bean,还有一些类似repository类)

2,V:处理数据显示的部分:xml

3,C:Activity处理用户交互问题:Activity


优点:便于UI视图的显示和界面的分离

特点:1,耦合度低:代码的关联程度不是很高,可以拆解达到解耦的目的

           2,可扩展性好

           3,模块职责划分明确


MVC

      当用户出发事件的时候,view层会发送指令到controller层,接着controller去通知model层更新数据,model层更新完数据以后直接显示在view层上,这就是MVC的工作原理。

      view层和model层是相互可知的,这意味着两层之间存在耦合,耦合对于一个大型程序来说是非常致命的,因为这表示开发,测试,维护都需要花大量的精力。


MVC总结:

1,利用MVC设计模式,使得项目有了很好的可扩展和维护性

2,controller(控制器)是一个中间桥梁的作用

3,什么时候适合使用MVC

    当项目需求复杂,迭代频繁,又比较多,MVC模块化设计,使项目模块化且饱满


MVP

1,M:依然是业务逻辑和实体模型

2,V:对应于Activity,负责view的绘制以及用户交互

3,P:负责完成View与model间交互(实现通过接口)

更加耦合低


MVP

      最明显的差别就是view层和model层不再相互可知,完全的解耦,取而代之的presenter层充当了桥梁的作用,用于操作view层发出的事件传递到presenter层中,presenter层去操作model层,并且将数据返回给view层,整个过程中view层和model层完全没有联系。

      看到这里大家可能会问,虽然view层和model层解耦了,但是view层和presenter层不是耦合在一起了吗?

       其实不是的,对于view层和presenter层的通信,我们是可以通过接口实现的,具体的意思就是说我们的activity,fragment可以去实现实现定义好的接口,而在对应的presenter中通过接口调用方法。

       不仅如此,我们还可以编写测试用的View,模拟用户的各种操作,从而实现对Presenter的测试。这就解决了MVC模式中测试,维护难的问题。

      当然,其实最好的方式是使用fragment作为view层,而activity则是用于创建view层(fragment)和presenter层(presenter)的一个控制器。

MVC与MVP相比,则性能上不好,activity厚重

在MVP设计模式中,Model数据层与View视图层是通过Presenter层来实现的。

bean包---model层

如何设计接口

P:数据与视图交互:

例如IUserBiz接口

1.定义的接口方法,

2.实现类进行耗时操作, 

3.然后让view层的activity去接该接口。


MVVM


MVVM

    相比MVP,presenter层换成了viewmodel层,还有一点就是view层和viewmodel层是相互绑定的关系,这意味着当你更新viewmodel层的数据的时候,view层会相应的变动ui。


1,Model:实体模型(数据模型),提供数据接口,供下面调用

2,ViewModel层:(不会更新UI,主要做的是业务逻辑层),负责完成View与Model间的交互,负责业务逻辑,ViewModel与View通过DataBinding进行数据绑定

3,View层:对应Activity与xml,负责view的绘制以及用户交互,初始化控件,不处理数据,不涉及业务逻辑。



以上部分内容参考http://www.apkbus.com/blog-705730-60592.html

你可能感兴趣的:(MVC/MVP/MVVM)