《android-MVP模式的困惑》
什么是MVP模式呢？我的理解就是老的MVC架构模式的一种延伸，能体现一种面向接口编程的思想。之所以会有MVP，是因为MVC中，C即Controllor对应于Activity或者Fragment。他们负责的东西太多了。比如：控件的初始化，网络请求，数据绑定，事件传递等。这显得我们的Controllor太过于臃肿(即又当C又当V)。而为了给Controllor减轻负担，于是就有了Presenter这个一个中间层，让Presenter负责完成View于Model间的交互。这有点像Web开发中的Service，什么业务逻辑都放在这里来处理，然后再与Action交互。 在网上也看到了很多图形来解释MVP与MVC的区别,如下: 这是mvc： 这是MVP： 主要区别是这样的： 还有就是真个项目的结构图： 通过上面的几个图我们不难发现，MVP模式中Presenter在这整个模式中显得很重要，那么问题来了(这也是我没用想明白的事情)： 1、Presenter通过接口的方式提高了代码的复用性，降低了耦合度，但是如果业务非常复杂的时候Presenter层会不会也会像MVC模式中的Activity一样显得很臃肿。 2、Presenter既然负责完成View于Model间的交互，那么它的生命周期怎么去控制。 3、Presenter层的出现，虽然降低了耦合度，但是相对于MVC来说代码量会增加部分