论开发框架的选择MVP，RxFlux2，Rxjava，Dagger2或在不需要

为什么要使用框架

使用框架，是为了提高生产效率。

框架就是这样一种套路，因为它已经通过某种范式，完成了对业务的解析、映射和分层，在充满未知的软件开发中，框架的存在使开发有一定规矩可循，使常见的问题容易得到解决，使开发人员更专注于具体业务。

一般来说，使用框架有这样几点好处：

1、加快开发速度。很多框架会帮你实现一些通用的、偏底层的实现、例如用IDE绘制软件界面、用Hibernate读写数据库、用EventBus传递事件、用HttpClient处理网络请求等（Android开发的框架会更多一些），除非是特殊的环境或有特别的诉求，否则没有开发者愿意花费大量的时间和精力，自己再造一遍轮子。

2、降低开发风险。还是造轮子的问题，每个轮子都会有缺陷，但是大家都在用的轮子，相对更加可靠，发现缺陷也容易及时得到修复。

3、方便团队协作。一般情况下，软件开发都是团队行为，团队开发就要求在成员之间协调一致地并行工作，这就要求接口一致、风格一致等，这会带来很多管理上的问题，而使用框架能较好地辅助这一点。

4、框架本身的优势。每个框架的出现都是为了解决某些问题，像我们今天要讨论的MVP、Flux和RxAndroid，都是为了解决日益复杂的业务逻辑导致软件不可控的问题，MVP的思路是“挪”，在MVC的基础上把业务逻辑从View中挪走；Flux的思路是“单向流”，用严格的单向数据流去实现比较容易跟踪检测的逻辑结构；RxAndroid的思路则是“链式逻辑”，用函数反应式编程的思想把逻辑、代码和线程统统简化为一条链式调用。



Flux是一个单向环，它实现业务的基本流程如下：
1、View响应操作并创建对应的Action
2、Action调用单例的Dispatcher去统一处理所有请求
3、Dispatcher持有所有Store对象，通过回调让Store处理数据
4、Store处理数据后，发出事件通知View更新解密
5、View接收Store的事件后，刷新页面


MVP优点：解决了Activity过于膨胀，把业务逻辑放在了Presenter层。
缺点：长期下去，业务繁杂，难以追踪逻辑运转和数据状态

RXFlux2有点：单向数据流，每个业务都是从某处进入Dispatcher单例中处理，再去往某处结束，中间不可能循环，这种机制能在同一个地方查询状态、改变状态、传播状态的变化，这就是MVP缺少的那种状态管理工具。
缺点：代码复用差，action类膨胀

Rxjava优点：主要用在业务逻辑处理上，把复杂的异步逻辑写成一条链式结构的代码，让逻辑和代码更加简洁
缺点：代码因为简洁变的紧凑，对排查问题增加了难度，给维护增加了难度

Dagger2优点：
1，解决多实例依赖创建问题。如：new A(new B(new C())
2，更好的管理对象的生命周期
3，代码规范，解偶好，扩展能力强。类的依赖都使用@Component、@Module、@Inject的规范实现。
4，最重要的：代码看起来比较装逼

如何选择

在框架上，没有最好的框架，只有合适的框架
特别很多框架是一种编程思想，不要为了使用而使用，能恰到好处的解决问题就是适合你的

特别当你有个界面很简单，没有很多的互动，就可以不使用框架，都写在activity里面，保持代码的简洁

总的来说不要过度设计，对于软件工程来说，完善的设计起不到应有的效果，反而是快速交付，快速迭代的策略越来越被证明是一种低风险的模式。