MVC/MVP模式的思考

思考1：现有的MVC开发模式不好吗？

Android目前MVC事实上解耦已经做到很好，View的部分交给layout xml去描述，Activity去做Control的部分，Model的部分交给ContentProvider 去做了。你发现这里的View和Model没有直接数据交换，是通过Activity这个Control进行连接的。所以说Google其实对MVC模式已经做到解耦基本成功。

思考2：为什么在后来的开发中，总是觉得Activity越来越重，而Model也越来越重？Google的MVC模式失灵了？

个人认为不是MVC模式失灵的问题，是人的问题，现代产品竞争简直惨烈，白领们每日每夜的加班，说穿了这是人性的问题。所以说是产品功能越来越重的问题，不是开发模式的问题。举例电视机OTT APP里面Activity/Fragment加起来几十个，还不包括大量的web页面。支付宝已经不是简单的支付功能和支付周边，简直是个百宝箱，对于那些没人用的功能，那就是个垃圾箱。一般人使用支付宝1～2%的功能就很了不起了，因为已经搞不清楚它到底还有什么是它不能干的。支付宝或者微信的开发已经重到不行了，无论服务器开发还是客户端开发都已经极其复杂了，真真同情那些程序员，脑容量是否够用。

思考3 MVP模式是最近谈的比较多的，如何评价它？

个人观点，MVP并不是新模式，还是MVC，只是对原来的C(Activity)进行的功能隔离，很多人认为Activity是View，这个错误的。 P的出现仅仅是把原来的C拆成新的C+P。准确点说是只是个术的提升，不是道的提升。

思考4 MVP既然是术，那一定也还是有点好处的。

P主要是C的延伸用于解决复杂度的问题，解决Activity的设计过大的问题，有了P带来一些好处，比如原来的Activity过大，导致业务逻辑太过复杂，所以有了P将原来的Activity的代码分为控制显示和与Model对接连个部分， Activity和P之间通过接口联系，P只通过控制接口进行业务代码的编写。很多文章提到解耦，这是不对的，其实基本上解耦的效果没有达到，只是C的代码做了拆分，在书写上跟原来比有优势，同样引入了新的问题，源码没有减少，反而多了大量的接口。

当然还带来另外的好处就是M只与P进行交互，不再与Activity进行交互，简洁了？？不见得，复杂了，也么有。感觉算不上好处第二点，P可以无需持有Activity的context,理论上可以存在较长时间，起到缓存的作用。在该层实现内存缓存的，减少Model层的厚度。其实应该在该层实现业务逻辑的缓存，特别是内存缓存，在model层实现是不对的，也是不好的。

所以P层的出现主要是解决了C模块的复杂度高的问题，解耦的效果有，但是没多少，缓存的作用有，也没多少。

其实杀手锏是在P->M的业务，见参考文献里面“最重要的老外文章”，P 和 M 做到最大的解耦，两层通过EventBus进行解耦。由于之前拆分出来的P仅仅它和M之间通过一个热插拔的方式进行数据流交换，通过几个简单的回调实现了数据流交换的本质。

“最重要的老外文章”里面的M 有一个很大的DataManager，通过RxJava实现异步请求的级联调用，很强大，一行代码完成一个业务，个人觉得不用这个也可以，不会影响框架的质量，RxJava确实很帅，但是隐藏了逻辑的细节,它对大量使用常规Http请求的应用很合适，对待特殊的就没办法。

所以，EventBus才是道，它实现了P和M的最小数据接口，而且实现很酷。另外otto也实现了类似的功能，不过个人不喜欢用注解写代码，它隐藏了细节，无法看到事物的本质，所在在个人的相关项目中，注解是很少出现的，除非它不可替代。

最近研究老子的道，老子的哲学真正的领悟，是真谛，我们解决问题的方法应该保持最自然的方式。少写几行代码和多写几行代码不是问题，重要的是接口是否保持最小，最纯洁。极其讨论java类的多层继承，你会发现它没解决什么问题，代码也是极其难懂。

另外，golang语言在设计上有许多优秀的地方，虽然有几处还是有争议，但是绝大部分还是优秀的。我在用它来解决公司的统计问题、编写服务器后端，在android开发中已经有相关应用见参考文献3，本人还在跟踪。