安卓框架学习之MVC、MVP、MVVM小结

安卓常用框架：MVP、MVC、MVVM。

MVC框架

MVC （Model View Controller 模型-视图-控制器）它实现了显示模块与功能模块的分离。
Model（模型）是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
View（视图）是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
Controller（控制器）是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示

Android对于MVC的理解

xml文件就对应于MVC中的View层，而各种java bean，还有一些类似repository类就对应于model层，
各种activity则对应于MVC中的Controller。
理解示例
比如xml中点击一个按钮 ，要进行网络下载操作，这个按钮就属于VIew层的，网络下载的代码写在一个NetWorkUtils类中，这个类就是model层，activity中使用btn.setonclickListener来实现View层和model层的连接，那么这个activity就对应Controller层。

优点

1、耦合性低
视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可
2、重用性高
MVC模式允许使用各种不同样式的视图来访问同一个服务器端的代码，因为多个视图能共享一个模型
3、生命周期成本低 可维护性高等

缺点

1、由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难
2、不适合小型，中等规模的应用程序
3、增加系统结构和实现的复杂性
对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，
并可能产生过多的更新操作，降低运行效率。
4、一般高级的界面工具或构造器不支持模式

MVP框架

全称：Model-View-Presenter ；
MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。

优点

1、模型与视图完全分离，我们可以修改视图而不影响模型
2、可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部
3、我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。
4、如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）
**逻辑清晰：将一个项目分为多个模块儿 适合于大项目，多人合作时候，更能清晰地分工，更方便的找到问题所在模块儿

缺点

1、类文件的大量激增
2、
由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。
还有一点需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了。比如说，原本用来呈现Html的Presenter现在也需要用于呈现Pdf了，那么视图很有可能也需要变更。

MVP与MVC区别

Model-View-ViewModel的简写
在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通Controller。

MVVM

MVVM模式的组成部分:模型、视图、视图模型、绑定器
Model-View-ViewModel的简写,它本质上就是MVC 的改进版。MVVM 就是将其中的View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。当然这些事 ViewModel 已经帮我们做了，它可以取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑

优点

  1. 低耦合
  2. 可重用性
  3. 独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计

缺点

1、view和model的绑定，使页面异常追踪变得 不方便，可能是view导致的bug,也可能使model导致的；
2、view和model的绑定，使对代码复用 变困难，例如：布局文件，绑定了model，如果多个页面共用一个model(个人也不建议这么干)，会导致model数据变多，内存开销变大，影响性能；

MVVM与MVP区别：

mvvm模式将Presener改名为View Model，基本上与MVP模式完全一致，唯一的区别是，它采用双向绑定(data-binding): View的 变动，自动反映在View Model，反之亦然。这样开发者就
不用处理接收事件和View更新的工作，框架已经帮你做好了。

MVVM的使用

个人理解：
长久以来个人还是比较习惯用MVC
MVP的话还是要看项目的逻辑复杂程度，一个逻辑比较简单的项目，个人感觉就没有必要再使用MVP了，因为他毕竟会导致类文件大量增加，但如果是大项目的话，就比较建议使用MVP了，模块儿化开发，各司其责，逻辑思路还是比较清晰地
MVVM的话的确是减少了Activity里面的代码量，但是又出现了bug追踪难的问题，有可能是Activity导致的，也有可能是xml中导致的，还有一个问题是，xml布局和data互相绑定后导致了布局的重用性大大的降低了