设计模式 MVC MVP MVVM 和 实践

MVC：

• 视图层(View)  对应于xml布局文件和java代码动态view部分
• 控制层(Controller)  MVC中Android的控制层是由Activity来承担的，Activity本来主要是作为初始化页面，展示数据的操作，但是因为XML视图功能太弱，所以Activity既要负责视图的显示又要加入控制逻辑，承担的功能过多。
• 模型层(Model)  针对业务模型，建立数据结构和相关的类，它主要负责网络请求，数据库处理，I/O的操作。
• 总结：
         具有一定的分层， model 彻底解耦， controller 和 view 并没有解耦
  层与层之间的交互尽量使用回调或者去使用消息机制去完成，尽量避免直接持有
  controller 和 view 在 android 中无法做到彻底分离，但在代码逻辑层面一定要分清
  业务逻辑被放置在 model 层，能够更好的复用和修改增加业务。

MVP：

       通过引入接口 BaseView ，让相应的视图组件如 Activity ， Fragment 去实现 BaseView ，实现了视图层的独立，通过中间层Preseter 实现了 Model 和 View 的完全解耦。 MVP 彻底解决了 MVC 中 View 和 Controller傻傻分不清楚的问题，但是随着业务逻辑的增加，一个页面可能会非常复杂，UI 的改变是非常多，会有非常多的case ，这样就会造成 View 的接口会很庞大。

MVVM：

        MVP 中我们说过随着业务逻辑的增加， UI 的改变多的情况下，会有非常多的跟 UI 相关的 case ，这样就会造成View 的接口会很庞大。而 MVVM 就解决了这个问题，通过双向绑定的机制，实现数据和 UI 内容，只要想改其中一方，另一方都能够及时更新的一种设计理念，这样就省去了很多在View 层中写很多 case 的情况，只需要改变数据就行。

MVVM与DataBinding的关系：

MVVM 是一种思想， DataBinding 是谷歌推出的方便实现 MVVM 的工具。

       看起来 MVVM 很好的解决了 MVC 和 MVP 的不足，但是由于数据和视图的双向绑定，导致出现问题时不太好定位来源，有可能数据问题导致，也有可能业务逻辑中对视图属性的修改导致。如果项目中打算用MVVM的话可以考虑使用官方的架构组件ViewModel 、 LiveData 、 DataBinding 去实现 MVVM 。

实践：

• 如果项目简单，没什么复杂性，未来改动也不大的话，那就不要用设计模式或者架构方法，只需要将每个模块封装好，方便调用即可，不要为了使用设计模式或架构方法而使用。
• 对于偏向展示型的app，绝大多数业务逻辑都在后端，app主要功能就是展示数据，交互等，建议使用mvvm。
• 对于工具类或者需要写很多业务逻辑app，使用mvp或者mvvm都可。