MVP模式详解与实践
本文介绍了MVP模式的基础知识，通过官方demo分析了MVP的结构和职责划分。contract作为合同定义接口，presenter处理业务逻辑并连接model与view，fragment作为视图层，activity负责初始化并关联各层。此外，还讲解了BaseView和BasePresenter的角色。
基础
mvc中，c指的是activity等，但它同时又承担了一部分的v工作，显得混乱冗长。而mvp中，将v当作activity，新添加一层做为p，m层不变。
对于官方的demo，整体包结构采用的是按模板划分包的。如下：
其中util指的是一些工具类，data指的是数据层(m层)，本demo中使用到bean也是定义在这里的。其余的就是一些各个任务模板。
总结每一个任务模板可以看出：每一个模板中有activity,presenter,contract,fragment四个类以及一些额外的本模板需要的类。各类的功能如下。
整体架构如下：
分类详解
contract
合同。定义了本模板中m与p层，p层与v层之间的接口。如下：
public interface AddEditTaskContract {
interface View extends BaseView<Presenter> {
void showEmptyTaskError();
void showTasksList();
void setTitle(String title);
void setDescription(String description);
boolean isActive();
}
interface Presenter extends BasePresenter {
void createTask(String title, String description);
void updateTask(String title, String description);
void populateTask();
}
}presenter
即p层，用于具体处理业务逻辑。也是m,v层交互的桥梁。并且，由于p的初始化并不是在v中，所以在p的构造函数中需要为v指定当前p是哪个。如下：
public StatisticsPresenter(@NonNull TasksRepository tasksRepository,
@NonNull StatisticsContract.View statisticsView) {
mTasksRepository = checkNotNull(tasksRepository, "tasksRepository cannot be null");
mStatisticsView = checkNotNull(statisticsView, "StatisticsView cannot be null!");
mStatisticsView.setPresenter(this);
}调用了v层的setPresenter，为v层指定p。
fragment
即v层。
activity
本demo中，所有的v层都是由fragment实现的，而activity是为p指定m与v的地方。如：
new StatisticsPresenter(
Injection.provideTasksRepository(getApplicationContext()), statisticsFragment);从这里可以看出，p层关联的v,m都是在activity中指定的，而不是直接在fragment中直接new一个p。只不过所有的v都需要有一个setPresenter()方法，用于指定该v关联的p是哪个。这个方法的调用在p的构造函数中。
BaseView
很简单，只有一个用来指定p的方法。这是因为所有的p都不是在v中进行的初始化，所以任何一个v都必须得具有设置P的方法。如下：
public interface BaseView<T> {
void setPresenter(T presenter);
}BasePresenter
它是将所有p的共性操作都抽取出来的。如下：
public interface BasePresenter {
void start();
} 其实，还应该有一个end()方法，用于将各个层的引用删除，防止出现内存泄露。
Model
对于一个应用来说，数据的来源往往有两个部分：本地以及服务器。而p层是往往不需要关注于数据到底来源于哪种渠道，它只需要有一个m层的引用，并可通过该引用拿到v层需要的数据即可，所以这里使用了代理模式。在代理类中对数据的来源进行了分类，并可以进行缓存。两个数据来源往往具有相同的操作，因此可抽象成一个接口。具体代码结构如下：
data包统筹数据，source包为数据来源，Task为数据的bean。local表示本地数据，remote为远程数据(服务器)。
对于本地数据的处理，采用了数据库——Contract定义的数据库字段名，Helper为数据库的helper，localdatasource为对数据库的操作。
TasksDataSource为数据操作的总接口，localdatasource与remotedatasource都实现了它。TasksRepository也实现了它。
对于P层来说，它应该只持有一个引用，通过该对象可以拿到数据，而不用判断这数据是来源于网络还是本地。因此，需要将local与remote进行统合，并将统合后的对象提供给p层，同时这个对象应该与local,remote实现相同的接口——因为三者在功能上是类似的，只不过统合对象对后两者进行了包装、分发。p层使用统合对象进行获取数据，具体的数据来源应该在m层中进行。
因此，使用TasksRepository对local与remote进行了统合，p层拿到的对象就是它的对象。其内部对数据的来源进行了判断。如下：
public void getTasks(@NonNull final LoadTasksCallback callback) {
checkNotNull(callback);
// Respond immediately with cache if available and not dirty
if (mCachedTasks != null && !mCacheIsDirty) {
callback.onTasksLoaded(new ArrayList<>(mCachedTasks.values()));
return;
}
if (mCacheIsDirty) {
// If the cache is dirty we need to fetch new data from the network.
getTasksFromRemoteDataSource(callback);
} else {
// Query the local storage if available. If not, query the network.
mTasksLocalDataSource.getTasks(new LoadTasksCallback() {
@Override
public void onTasksLoaded(List<Task> tasks) {
refreshCache(tasks);
callback.onTasksLoaded(new ArrayList<>(mCachedTasks.values()));
}
@Override
public void onDataNotAvailable() {
getTasksFromRemoteDataSource(callback);
}
});
}
}
private void getTasksFromRemoteDataSource(@NonNull final LoadTasksCallback callback) {
mTasksRemoteDataSource.getTasks(new LoadTasksCallback() {
@Override
public void onTasksLoaded(List<Task> tasks) {
refreshCache(tasks);//刷新内存缓存
refreshLocalDataSource(tasks);//刷新到数据库中
callback.onTasksLoaded(new ArrayList<>(mCachedTasks.values()));
}
@Override
public void onDataNotAvailable() {
callback.onDataNotAvailable();
}
});
}总结
1，使用Activity充当p,m,v直接建立联系的桥梁。使用fragment充当v。
2，对于model层，统一类管理数据的来源，不应将获取本地还是远程的判断放在p层中。并且，为提高访问速度，可能需要对数据进行内存缓存。
3，如果Activity的逻辑比较复杂，应使用MVP，如果比较简单可直接写在activity中。
扩展
上述示例中，数据的加载没有考虑在子线程中操作。可以考虑在m与p之前添加一个loader，由loader子线程中通过TasksRepository加载数据。demo来源。这个demo中主要采用的是mvp+loader+观察者模式。另参考Loader。
Loader：只负责提供子线程，供加载数据的方法运行在子线程中。
TasksRepository：为本地数据和网络数据提供代理，以及对加载到的数据提供缓存。
开始方法应该是p的start()，这里面直接调用了LoaderManager#initLoader()，也就是启动了Loader进行数据的加载。如下：
protected void onStartLoading() {
// Deliver any previously loaded data immediately if available.
if (mRepository.cachedTasksAvailable()) {
deliverResult(mRepository.getCachedTasks());//将缓存数据给返回
}
// Begin monitoring the underlying data source.
mRepository.addContentObserver(this);
if (takeContentChanged() || !mRepository.cachedTasksAvailable()) {
// When a change has been delivered or the repository cache isn't available, we force
// a load.
forceLoad();
}
}
数据加载结束后，对数据进行分类，并通知view进行展示。略。
在v中有刷新的操作，该操作会调用p的loadTasks()，它又会调用mRepository.refreshTasks()，该方法只是通知它里面的观察者调用onTasksChanged()方法。在上面的onStartLoading()中可以发现，loader是repository的一个观察者，所以最终会调用到loader的onTasksChanged()，它里面只是一个判断并调用forceLoad()。这就是观察者模式，同时也保证了数据的加载永远走在子线程中。
扫一扫
3237
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
