MVP中Model的进一步细化——DataManager

前言

首先上篇文章讲到的是依赖注入(dagger),然后我使用rxjava, retrofit, dagger2, mvp做了一个练手app——githubQuery,算是第一次尝试吧。再是mvp用的是我自己的一个框架EasyMVP。然后在model层我学习了一个老外的想法,抽出来了一个叫datamanager的东西,它属于model层,用于过滤和操作从model层得到的数据。主要的目的是方便dagger提供单一的数据层依赖,并且减少presenter层的代码量。这几个库都不好上手,但是我觉得多用多写就好了,我现在已经在用这套方法在做别的项目了。

依赖注入图

MVP中Model的进一步细化——DataManager_第1张图片
gtihubquery依赖注入图1.png

MVP中Model的进一步细化——DataManager_第2张图片
githubquery依赖注入图2.png

可以看到我在ActivityComponent中的API是抛出了很多的inject方法用来注入其他所有的activity,但是这种做法适合小项目,项目大了之后,如果每个activity的依赖需求不同还是很麻烦,所以最好一个activity一个component。对照这个图看代码基本问题不大,我记得当时对于@Inject这个注解的理解不是很深刻!

DataManager相当于是model所有数据源的代理层,作为ApplicaitonComponent的API暴露出来,然后作为ActivityComponent的依赖注入进去。

@Inject()

如果@Inject标注的是构造方法。那么表明这个类的对象也是依赖注入图里面的一员,前提是这个构造函数里面的所有参数都是来自依赖注入图(@provide)。

项目架构图

MVP中Model的进一步细化——DataManager_第3张图片
githubquery项目架构图.png

注意,我的mvp开发模式是将activity,fragment作为presenter。

在这里DataManager就是整个架构的核心了。因为我们使用的是rxjava+retrofit,自然要有一种流的思想。你可以这样想,一个数据流从hepler类流到datamanager,然后在这里做你所需要的变换。比如你需要把所有学生姓名的首字母大写,但是api返回的元数据是没有大写的。这样做其实就是为了给activity等presenter瘦身。我贴出我的DataManager的代码:

/**
 * Created by Zane on 16/1/26.
 */
@Singleton
public class DataManager {

    private GithubApiService githubApiService;
    private Context mContext;

    @Inject
    public DataManager(@ContextType("MyApplication")Context context, GithubApiService githubApiService){
        this.githubApiService = githubApiService;
        mContext = context;
    }

    //对用户信息进行一层过滤或者操作,然后在presenter中去调用这个方法.
    //当然我在这里做的操作毫无意义,但是如果有需要还是会减少activity活着fragment中的代码量。
    //presenter只负责调用。然后获得数据而不管代码的实现
    public Observable getUserInfo(String userName){

        return githubApiService.getUserInfo(userName)
                .map(new Func1() {
                    @Override
                    public Users call(Users users) {
                        String name = users.getName();
                        users.setName(name + " datamanager");
                        return users;
                    }
                })
                .flatMap(new Func1>() {
                    @Override
                    public Observable call(final Users users) {
                        return Observable.create(new Observable.OnSubscribe() {
                            @Override
                            public void call(Subscriber subscriber) {
                                subscriber.onNext(users);
                            }
                        });
                    }
                });

    }

    //对库的信息进行一层过滤
    public Observable> getReposInfo(String userName){
        return githubApiService.getReposInfo(userName);
    }

}

我将用户的名字后面加了一个datamanager,在这里虽然没什么意义,但是要体现datamanager的作用所在。

不足

没有任何东西是完美的。

这里如果只有一个DataManager的话,那么如果数据量一大,这个类会变得非常的臃肿和复杂。

所有东西都是在不断尝试吧,贴出这个思想创始人的文章:Android Application Architecture

好了,去上课了。。近代史!

你可能感兴趣的:(MVP中Model的进一步细化——DataManager)