我经常想在项目中使用 ORM 来简化操作,但是最终都将这个念头打消。主要有以下几点原因:
不过最近,我开始使用一个简单的设计模式,使用 RxJava 来提供一个简单的数据库访问管理。 我称它为 “Async Rx Read” 设计模式,很渣的一个名字哈,不过是我能想到最好的了,命名总是程序员的难题嘛。
Android 开发中有一条很重要的设计原则,永远不要在主线程执行 I/O 操作,显然这条规则对数据库访问也适用。 RxJava 很适用于解决这个问题。 在以前,我通常为每个 table 创建一个 Java 类,然后通过我的 SQLiteOpenHelper 来管理这些 table。 现在使用这个新的方法后,我将这个工具类扩展成所有事物读写 SQL table 的唯一入口。 我们来想个简单的例子:一个由 UserTable 类管理的 USERS 表:
// UserTable.java
List<User> getUsers(SQLiteDatabase db, String userId) {
// select * from users where _id = {userId}
}
上面的方法有一个缺点,就是你一不小心可能会在主线程调用它,这里面是由调用者确保它是在后台线程中被执行的
(如果需要更新 UI 的话,再将结果返回给主线程)。而不是依赖一个线程池管理,或者更糟点,使用 AsyncTask
管理,
我们将使用 RxJava 替我们管理线程模型。
让我们重写这个方法返回一个 callback :
// UserTable.java
Callable<List<User>> getUsers(SQLiteDatabase db, String userId) {
return new Callable<List<User>>() {
@Override
public List<User> call() {
// select * from users where _id is userId
}
}
}
实际上,我们只是重构了一下这个方法返回一个 lazy result ,使得 database helper 可以将这个
result 转变成一个 Observable
:
// MySqliteOpenHelper.java
Observable<List<User>> getUsers(String userId) {
return makeObservable(mUserTable.getUsers(getReadableDatabase(), userId))
.subscribeOn(Schedulers.computation()) // note: do not use Schedulers.io()
}
注意到将 lazy result 转换成一个 Observable
时,helper 强制 subscription 运行在后台线程
(这里使用的是 computation scheduler;不要使用 Schedulers.io()
因为它是由 unbounded executor 支持的)。
这样调用者就不必担心这个方法会阻塞主线程了。
最后,makeObservable()
方法的实现很简单(而且是完全通用的):
// MySqliteOpenHelper.java
private static <T> Observable<T> makeObservable(final Callable<T> func) {
return Observable.create(
new Observable.OnSubscribe<T>() {
@Override
public void call(Subscriber<? super T> subscriber) {
try {
subscriber.onNext(func.call());
} catch(Exception ex) {
Log.e(TAG, "Error reading from the database", ex);
}
}
});
}
现在,我们的 database 读取已经变成了 observables
,保证查询是执行在后台线程的。
访问数据库操作也是很标准的 Rx code:
// DisplayUsersFragment.java
@Inject
MySqliteOpenHelper mDbHelper;
// ...
mDbHelper.getUsers(userId)
.observeOn(AndroidSchedulers.mainThread())
.subscribe(new Action1<List<User>>()) {
@Override
public void onNext(List<User> users) {
// Update our UI with the users
}
}
}
如果你不需要返回结果更新你的 UI,那么你只需要 observe 一个后台线程。
然后你的 database 层会返回 observables,当获得结果时很容易将它组合变换。
例如,假定 ContactTable
是一个底层类, model (User class) 对它是不可见的,
它应该返回底层 object (可能是 Cursor
或者 ContentValues
)。然后你可以用
Rx 去 map
这些底层值,把它们转换成你的 model 类,实现更加清晰的分离层。
两个提示:
你的 Table 类不应该包含 public 方法:只能有 package 的 protected 方法(仅允许相同 package 内的 Helper 访问 ) 和 private 方法, 其他类不能直接访问 Table 类。
这个方法对依赖注入兼容性很好:很轻松就可以同时实现 database helper 和注入单个 Table (意外收获:使用 Dagger 2,你的 table 可以拥有自己的组件,因为 database helper 是实例化它们所需的唯一参考资料 )。
这是一个很简单的设计模式,它显著提升了 RxJava 在项目中发挥的效果。 我正在扩展这层结构,让它可以为 list view adapter update 提供更灵活的通知机制 (和 SQLBrite 提供的不同),会在以后的文章中介绍。
这项工作还在进行中,欢迎反馈。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8