android model层架构

Favor composition over inheritance.

#示例图

图画的有点丑，见谅。简单说一下，Presenter就是Mvp中的P，View即MVP中的V需要什么功能都由Presenter提供，事实上Presenter也是借助Usecase来完成相应功能的，Presenter持有完成所有功能的Usecase（注：每一个Usecase完成一个功能，比如登录就是LoginUsecase，注册就是RegisterUsecase）。

          为什么一个Usecase只完成一个功能？

1，单一职责原则。这个不多说。

2，我倾向于使用组合去完成功能的复用，而不是继承。就像积木，需要哪个材料就选取哪个材料，精简、高效。因为最小功能单位的复用性才算最大的。

事实上，不管View层需要什么功能，直接调用presenter.execute（BaseRequest request）方法即可。当然request是具体的请求对象，继承BaseRequest。也就是说一个request对应Usecase。我们可以在Presenter中维护一个UsecaseManager实现通过request得到对应的Usecase。

Usecase是一个抽象类，上代码

```

public abstract class Usecase{

privateSubscriptionmSubscription= Subscriptions.empty();

public void execute(Q request,Observer subscriber){

unsubscribe();

mSubscription= buildUsecaseObservable(request)

.subscribeOn(Schedulers.io())

.observeOn(AndroidSchedulers.mainThread())

.subscribe(subscriber);

}

protected abstractObservable buildUsecaseObservable(Q request);

public voidunsubscribe(){

if(!mSubscription.isUnsubscribed()){

mSubscription.unsubscribe();

}

}

}

```

所以实现一个Usecase的步骤是继承Usecase，覆写buildUsecaseObservable方法，通常Usecase需要一个Repository来完成相应的操作，就在构造函数中通过Dagger2注入进来。若是明确只需要通过网络发起请求，可以直接注入一个Api，然后再Api中完成相应操作。

本片可能写的很没有逻辑，但是中心思想是使用组合而非继承，希望对你有所启发。