一、 Data Repository意义
1、 据了解物流项目也有几年历史，迭代更新了好几个版本，有必要进行一些技术沉淀，架构沉淀。
2、 推进基础组件建设落地。
3、 可能面临一些解耦等各种难题，长痛不如短痛，颗粒度可以逐渐从粗到细。
二、 没做组件化之前的是这样的(物流项目)，暂时不讨论业务层的架构设计模式(目前是mvc)
问题分析:
优点：
1、 因为各种数据提供者和主工程同属于一个空间内，方便及时即用。
2、 只要维护一个工程即可。
缺点：
1、业务和各种数据提供者严重柔和在一起，业务层要时刻关注各种数据提供者的内在变化，一旦发生变化需及时对应大量调整。比如网络框架，android的网络框架一直在不断演变。
2、开发者使用各种数据源不统一，人员更替接手项目困难重重，维护成本及高。
3、开辟新项目时，移植成本相当高，比如，我们要构建委托项目时，各种数据源需要一个个拷贝，还不排除数据源内部有啥其它依赖，相当痛苦，新开一个项目时还好，开辟多个新项目时，恐怖程度，大家可想而知。
三、网络组件化之后项目是这样的
问题分析：
优点：
1、 网络已组件化，主项目中的网络请求的大片代码已撤离到了网络组件中，降低了业务代码与网络处理相关代码的耦合度，这个时候，职责划分思想已浮出水面，业务和网络层面职责不断清晰。
缺点：
2、 虽然已把网络相关的大部分code移植到网络组件中，不幸的是主工程中RxNet依然隶属于第三网络库，仍然潜在着网络库迭代带来的巨大工作量的痛点。
3、 其它数据源提供者仍然耦合在主工程中，新项目来临时依然难逃其它各种数据源相关的各种文件的移植工作量
四、提供DataRepository之后项目是这样的
问题分析：
缺点：
1、需要维护两个工程，而且需要投入大量成本把DataRepository不断完善健壮。
优点：
1、 把各种数据源全部集中起来，统一管理，对外暴露相关action，业务层你需要哪种数据源，我就给你什么，业务层不需要关心我在哪儿，我是怎么实现的。我告诉你怎么用就行了。
2、 部分单纯只与数据相关的逻辑可以放到DataRepository，向 上层 屏蔽数据处理细节，就不必关心 Model 层传递过来的数据到底是来至网络还是来至数据库还是来至本地文件等等。
3、 我们引入了 RxJava，但是只有网络层中的 Retrofit 能返回 Observable 对象，其他模块都是返回的还是一些非 Observable 的 Java 对象，为了能在整个 Presenter 层中都体验 RxJava 带来的美妙之处，因此可以通过 Data Repository 做一层转换；
4、 主项目代码不那么混乱了，业务层和数据源职责清清楚楚。新人投入开发时，不需要东找西找数据提供者，简单告诉它如何使用即可。可以把DataRepository做的更加灵活一些，能达到分发角色最好。
5、 那么现在我们要构建委托项目啦，其实这时候我们就没那么痛苦了，只要轻松依赖一下Model Layer即可，项目就拥有了使用各种数据源的所有功能的能力,其实我想
表达的初衷是，实现一个同样的功能，以重用的方式去实现，而非搬运代码的方式。
五、 实现方案
实现方式可以根据各平台的各自特性个性化实现
Android已经使用策略模式+简单工厂模式+代理模式+泛型实现
