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的绘制以及用户交互，初始化控件，不处理数据，不涉及业务逻辑。