### 参考链接 * [简述MVC框架模式以及在你（ANDROID）项目中的应用](http://www.cnblogs.com/John-Chen/p/4458823.html) * [【译】Android开发中的MVP架构](http://www.imooc.com/article/3141) * [安卓项目中MVP模式实践](http://www.imooc.com/article/1812) ### MVC模式 ### 最主要的是得想办法做到解耦以及提升应用的稳定性。 * **MVC 是Model、View、Controller 三部分组成的。其中View 主要由xml 布局文件，或者用代码编写动态布局来体现。Model 是数据模型，其实类似javabean，不过这些JavaBean 封装了对数据库、网络等的操作。Controller 一般由Activity 负责，它根据用户的输入，控制用户界面数据的显示及更新model 对象的状态，它通过控制View 和Model 跟用户进行交互。** * MVC是一种框架模式，而不是设计模式，GOF把MVC看做3种设计模式，观察者模式、策略模式、组合模式，其核心在观察者模式。 * 框架模式与设计模式的区别 * 对于框架模式来说，是对代码的重用；而对于设计来说通常是对设计的重用。 * 框架面向于一系列相同行为代码的重用；而设计则面向的是一系列相同结构代码的重用，架构介于框架和设计之间 - 在软件开发领域有3种级别的重用 - 内部重用 - 代码重用 - 应用框架的重用 常见的框架模式有：MVC、MVVC、MTV、CBD、ORM、MVP 简而言之：**框架是大智慧，用来对软件设计进行分工，设计模式是小技巧，对具体问题提出解决方案，以提高代码复用率，降低耦合度** * MVC与Android的各个组件的对应关系： * View：自定义View或ViewGroup，负责将用户的请求通知Controller，并根据model更新界面； * Controller：Activity或者Fragment，接收用户请求并更新model； * Model：数据模型，负责数据处理相关的逻辑，封装应用程序状态，响应状态查询，通知View改变，对应Android中的datebase、SharePreference等。  * 视图（View）：用户界面。 * 控制器（Controller）：业务逻辑 * 模型（Model）：数据保存 #### 各部分之间的通信方式如下 ####  所有的通信都是单向的 1. View 传送指令到 Controller 2. Controller 完成业务逻辑后，要求 Model 改变状态 3. Model 将新的数据发送到 View，用户得到反馈 对于android本身来说，其界面部分的开发就涉及到了模型---视图---控制器3者的交互，在android中视图View层一般采用XML文件进行界面的描述；而对于模型model部分则大多对应于本地的数据文件或网络获取的数据体，很多情况下我们对这些数据的处理也会在这一层中进行；最后的控制器Controller部分则由Activity承担。 **一般情况下，在Activity中获取数据以及界面元素，并将两者进行绑定，但其逻辑不能过于复杂，因为android中规定一个Activity的响应时间是5秒，如果超过这个时间可能会被回收掉。** 在Android 的UI 系统中，控制器Activity 主要起到的作用就是解耦，将视图View 和模型Model 进行分离，两者在Activity 中进行绑定或完成其他逻辑。总体来说， MVC 更适合于规模比较大的项目 相关资料可参阅[这里](http://isux.tencent.com/learn-android-from-zero-session3.html)的三篇博客  ### MVP模式（Model View Presenter） ###  MVP 模式将 Controller 改名为 Presenter（主持人、中间人），同时改变了通信方向。 #### MVP模式的三个角色 #### 1. Presenter一一交互中间人 Presenter 主要作为沟通View 和Model 的桥梁，它从Model 层检索数据后，返回给View 层，使得View 和Model 之间没有耦合，也将业务逻辑从View 角色上抽离出来。 2. View一一用户界面 View 通常是指Activity 、Fragment 或者某个View 控件，它含有一个Presenter 成员变量。通常View 需要实现一个逻辑接口，将View 上的操作通过会转交给Presenter 进行实现，最后， Presenter调用View 逻辑接口将结果返回给View 元素。 3. Model一一数据的存取 对于一个结构化的App 来说， Model 角色主要是提供数据的存取功能。Presenter 需要通过Model层存储、获取数据， Model 就像一个数据仓库。更直白地说， Model 是封装了数据库DAO 或者网络获取数据的角色，或者两种数据获取方式的集合。 **由此可见Model-View一－Presenter 三者之间的关系都是松耦合， Presenter 持有的View 、Model 引用都是抽象，这样当UI发生变化时，我们只需要替换View 即可；而数据库引擎需要替换时，只需要重新构建一个实现ArticleModel 接口的类实现相关的存取逻辑即可。这样使得View 、Model 、Presenter三者之间可以独立的变化，测试也非常方便，可扩展性、灵活性都很高** 1. 各部分之间的通信，都是双向的。 2. View 与 Model 不发生联系，都通过 Presenter 传递。 3. View 非常薄，不部署任何业务逻辑，称为"被动视图"（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。 * MVP 模式会解除View 与Model 的耦合，同时又带来了良好的可扩展性、可测试性，保证了系统的整洁性、灵活性。 * MVP 模式可以分离显示层和逻辑层，它们之间通过接口进行通信，降低糯合。 * 理想化的MVP模式可以实现同一份逻辑代码搭配不同的显示界面，因为它们之间并不依赖于具体，而是依赖于抽象。这使得Presenter 可以运用于任何实现了View 逻辑接口的UI ，使之具有更广泛的适用性，保证了灵活度。 * 对于一个可扩展、稳定的应用来说，我们需要定义分离各个层， 主要是UI层、业务逻辑层和数据层。 * MVP 并不是一个标准化的模式，它有很多种实现方式,只要保证我们是通过Presenter 将View 和Model 解耦合、降低类型复杂度、各个模块可以独立测试、独立变化，这就是正确的方向。 **MVC 的耦合性还是相对较高， View 可以直接访问Model ，导致3 者之间构成回路。因此， MVP 与MVC 的主要区别是， MVP 中的View 不能直接访问Model ，需要通过Presenter 发出请求， View 与Model 不直接通信。** ### MVVM模式 ###  MVVM 与MVP 非常相似，唯一的区别是View 和Model 进行双向绑定（ data-binding ），两者之间有一方发生变化则会反应到另一方上。而MVP 与MVVM 的主要区别则是， MVP 中的View更新需要通过Presenter，而MVVM 则不需要，因为View 与Model 进行了双向绑定，数据的修改会直接反应到View 角色上，而View 的修改也会导致数据的变更。此时， ViewModel 角色需要做的只是业务逻辑的处理，以及修改View 或者Model 的状态。MVVM 模式有点像ListView 与Adapter 、数据集的关系，这个Adapter 就是ViewModel 角色，它与View 进行了绑定，又与数据集进行了绑定，当数据集合发生变化时，调用Adapter 的notifyDataSetChanged 之后View 就直接更新，它们之间没有直接的耦合，使得ListView 变得更为灵活。 MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。