以下对于MVP、MVVM的阐述纯属跟人观点，并不是一个成熟的结论。发文主要希望能和大佬们一起讨论。不作为学习对象，不推荐新人阅读。
对于小团队，不要为了追求模式而耽误工期。但不要等到项目无法迭代时，再想到模式。
设计模式容易成瘾，本人已经不会正常写代码了。
先说一个本人特别成瘾的东西：
很奇怪的是，这两年都少有人讨论这个东西。
由于Java这门面向对象语言的骚特性，仿佛拿到对象就拿到了全世界。
你可能经常看到，一个对象，被疯狂传递，被多个地方持有，层级关系混乱，甚至找不到谁在真正管理它。
EIT造型告诉我们，引擎可以控制轮胎，但轮胎只能反馈引擎。
简单地说：如果两个类，互相持有了彼此的对象，你就值得考虑，到底谁是老大，谁是小弟。
再说MVP：
如果去网上搜MVP，你一定看过这个图
网上大多数文章是在说，不能在Activity(fragment)中写太多，你用该写一个presenter，然后把逻辑丢给presenter去操作，Activity(fragment)只写关于view的东西。
写完一个大模块发现，哇擦，presenter有上千行，接口里有几十个方法，exo???
其实并非文章说的不在理，而是MVP并不仅仅是换一个地方放代码，而是强调presenter在模块的作用。
以下是我对MVP的理解。
几点解释：
1、ViewListener：在Google官方的MVP例子中，可以看到view层会持有presenter对象，即view可以直接控制presenter，个人认为这并不优雅。
举个例子，如果按下一个红色按钮，就能升职加薪。
例子的写法：红色按钮.click()--->presenter.升职加薪()--->升职加薪
我的写法是：红色按钮.click()--->presenter.红色按钮click()--->升职加薪
区别在于，决定红色按钮功能的分配，在于presenter而不是view
当然实际开发中，会把view的多个事件合并传输，不会为了一个按钮给presenter开一个接口。
2、Action：Action是什么鬼？
Action是为了给presenter减负，在上一点上，提到了presenter分配功能，而最终实现是在model。如果一个功能，是多个model串联起来的，那么action的作用就出现了。诶，等一下，这不就是presenter的作用吗？实际上我对Action的定义，就是承担一部分presenter。
举个例子：比如升值加薪包括，努力工作，项目上线，项目成功三个步骤
没有action的情况下：升职加薪 = 努力工作()+项目上线()+项目成功();
有action的情况下：升职加薪 = action.升职加薪() = 努力工作()+项目上线()+项目成功()。
当浏览presenter时，我希望在presenter中看到的是红色按钮会发生什么，而不是红色按钮会具体做去什么。
为复杂逻辑套壳，让presenter层这个最臃肿的模块易于阅读，就是action的存在的意义。
简单总结一下：我理解的MVP，是强调presenter调度作用的一种模式。以至于ViewListener、Action这些，完全取决于开发习惯和代码规范，是实现的手段罢了。
再说MVVM：
等待编辑。
