## MVC+MVP+MVVM 项目实例 ## MVC MVC全名 Model View Controller 模型（model）-视图（view）-控制器（controller） 一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。 - M是指业务模型，处理数据，业务逻辑； - Model 层就是 **JavaBean 实体类**，用于保存实例数据 - 与View无关，而与业务相关，对数据库的操作、网络的操作都应该在Model里面处理，当然对业务计算机等操作也是必须放在该层的。就是应用程序中二进制的数据。 - V是指用户界面 - View 层其实就是程序的 UI 界面，用于向用户展示数据以及接收用户的输入 - Android中，View一般采用XML文件进行界面的描述， - C则是控制器 - Controller 控制器用于更新 UI 界面和数据实例 - Android中Controller重任通常由Activity和Fragment担当，暗含了不要在Activity中写代码，要通过Activity交割Model业务逻辑层处理，另一原因是Android中Activity响应时间是5s，如果耗时操作放在这里，程序很容易被回收掉  - 缺点：Activity既是View又是controller,没有实现VC的分离、 ## MVP - MVP模式的核心思想 把Activity中的UI逻辑抽象成View接口，把业务逻辑抽象成Presenter接口，Model类还是原来的Model类  - View：负责绘制UI元素，与用户进行交互（Android中体现为Activity） - Model：负责存储、检索、操作数据（有时也实现一个Model interface 用来降低耦合） - Presenter：作为View与Model交互的中间纽带，处理与用户交互的负责逻辑 - View interface：需要View实现的接口，View通过View Interface与Presenter进行交互，降低耦合，方便进行单元测试 - **优点**： - 降低耦合度，实现了Model和View真正的完全分离，可以修改View而不影响Model - 模块职责换分明显，层次清晰 - 隐藏数据（**Model里面如何操作，View不需要知道，View真正关心的是Model的处理结果**） - Presenter可以复用（比如：多个Activity使用同一个Presenter，ex：登录注册可以使用一个Presenter） - 利于测试驱动开发 - View 可以进行组件化 - 代码灵活性 - Activity只处理生命周期的任务，代码简洁 - 视图逻辑和业务逻辑抽象到了View和Presenter中，提高阅读性 - Presenter被抽象成接口，可以有多种具体的实现 - 业务逻辑在Presenter中，避免后台线程引用Activity导致内存泄漏，但是有时候如果Presenter持有view的引用，可是view关闭，也有可能造成Activity的内存泄漏 - **缺点** - Presenter除了对应的应用逻辑之外，还有大量的View-->Model,Model-->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难 - 由于视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁 - 如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要更改，则Presenter也需要更改。 - 额外的代码复杂度及学习成本 MVP设计原则（常用的） - 一个Activity对应一个View - 通常情况下，一个View对应一个Presenter，在业务复杂时，一个Activity可对应多个Presenter - 将View与Presenter抽象成接口 ### MVC和MVP对比 ###  ### MVP与MVC对比总结 ### - MVC允许View和Model直接通讯 - MVP中，所有对Model的交互都由Presenter内部来完成 - MVP中，View通常会抽象化出来系列的接口（面向接口编程） - MVP相对MVC而言，大大降低了耦合度（Activity不再进行复杂的操作），层级更明显，更现实单元测试 - MVP的缺点：类文件会越来越来多，会“大爆炸”，有一定的学习成本。