Android中的"架构"选择

起初接触Android开发是在2014年的毕业季，当时互联网的就业机会很多，外包公司等都在一个劲儿的强人，

        进到公司一般都会问掌握了些什么，然后就亮出了自己的客户端

                  


MVC : View   ->  Controll  ->   Module     

View： 指的是Activity,Fragment等视图页面

Controll：控制器

Module： 业务模型

MVC的优缺点：

MVC这样做的好处是 所有的业务逻辑放在Activity中处理，包含简单的UI逻辑（比如显示一个对话框）、异步网络请求(比如启动一个

AysncTask

做网络请求)、存储逻辑(比如在

onCreate()

中读取文件，在

onDestroy()

中保存文件)。这个时候对“MVC”架构并没有深入的了解，仅仅从字面有意义上认为App应该分为Model-View-Controller三层，而对于Android平台，想当然的认为View是属于XML布局文件的，Controller是属于Activity的，Model需要自己的实现，于是产生了这种架构。很明显，这种“架构”在可扩展性、灵活性甚至功能性上都是有问题的

   经过了一年的时间历练，遇上了一些业务相对复杂的项目，忍受不了Activity内的方法太多太乱，于是开始尝试使用MVP架构：



M-Model-模型、V-View-视图、P-Presenter-表示器。
 

View不直接与Model交互，而是通过与Presenter交互来与Model间接交互。 

Presenter与View的交互是通过接口来进行的。 
通常View与Presenter是一对一的，但复杂的View可能绑定多个Presenter来处理逻辑。

对于多人协同合作的MVP而言，这种方式增加了团队之间合作的灵敏方式。但是由于业务的增多，产生了类爆炸的状况....