随着Android架构的不断演进,从最初的MVC到MVP再到MVVM,变化的只有M和V层之间的部分,M和V层开发者彷佛都已经统一了意见。html
但据我在GitHub上看过的各类项目代码而言,许多人仅仅停留在字面上的理解,而没有真正的处理好三层间的边界。android
今天,咱们来聊一聊MVX中的Model。git
以MVVM
架构为例,Model
层的职责主要是数据的获取和存储而后将数据返回给ViewModel
层。github
在上面的图解中,咱们分离出了一个仓库类Repository
,这是Google开发架构指南中推荐的作法。数据库
对此,在指南中这样解释:编程
ViewModel的一个简单的实现方式是直接调用Webservice获取数据,而后把它赋值给User对象。虽然这样可行,可是随着app的增大会变得难以维护。ViewModel的职责过多也违背了前面提到的关注点分离(separation of concerns)原则。另外,ViewModel的有效时间是和Activity和Fragment的生命周期绑定的,所以当它的生命周期结束便丢失全部数据是一种很差的用户体验。相反,咱们的ViewModel将把这个工做代理给Repository模块。缓存
所以,Repository 就成了一个很关键的模块,咱们在这里处理全部关于数据的事情,包括服务器
从SharedPreference或者数据库或者服务器获取数据架构
使用SharedPreference或者数据库缓存数据app
对请求参数的处理以及将返回数据处理为ViewModel层但愿的类型
接下来,咱们围绕着这三点来聊聊Model。
在我看过的大部分代码中,包括我本身之前也并无意识到应该在Model层中经过SharedPreference存取数据,缘由多是没这个意识或者是由于写在其它地方也没影响到流程。
好比咱们须要根据SharedPreference
中缓存的用户Id来加载用户的详细信息,而且将返回结果也缓存在SharedPreference
中。这种场景下常常会出现以下的代码:
/// View
final userId = spUtil.getString("userId")
viewmodel.getUserDetail(userId)
.subscribe({
//成功以后缓存详情
spUtil.putString("userDetail")
},{})
/// ViewModel
fun getUserDetail(userId:String):Observable = repository.getUserDetail(userId)
/// Model
class UserRepository constructor(private val remote){
/// 获取用户详情
fun getUserDetail(userId:String):Observable = remote.getUserDetail(userId)
}
复制代码
可是SharedPreference
的做用其实相似于数据库,若是DB应该位于Model层,那么SharedPreference
也一样,并且也不会出现参数传来传去的状况,改造以后的代码以下:
/// View
viewmodel.getUserDetail()
.subscribe({
//success
},{})
/// ViewModel
fun getUserDetail():Observable = repository.getUserDetail()
/// Model
class UserRepository constructor(private val remote:UserService,private val spUtil:SpUtil){
/// 获取用户详情
///
/// 经过 [spUtil] 拿到缓存的userId,获取到详情后再用[spUtil]进行缓存
fun getUserDetail():Observable {
final userId = spUtil.getString("userId")
return remote.getUserDetail(userId).doOnSuccess{
spUtil.putString("userDetail")
}
}
}
复制代码
我经常看到一些开发者只是把Repository看成是一个摆设,或者是一个象征性的东西,而没有实质上发挥它该有的做用。
好比有这样一个场景:展现文章详情,若是文章之前已被缓存过,那么直接获取缓存的数据,不然拉取服务端的数据并缓存到本地数据库。
就会出现以下的代码:
/// ViewModel
fun getArticleDetail(articleId:String):Observable {
return repository.getLocalArticleById(articleId)
.onErrorResumeNext {
repository.getArticleById(id)
.doOnSuccess { repository.insertArticle(it) }
}.doOnSuccess{
// 数据转换成View层须要的数据
renderUI(it)
}
}
/// Model
class ArticleRepository constructor(private val remote:ArticleService,private val local:ArticleDao){
/// 根据[articleId]从数据库中查找文章详情
fun getLocalArticleById(articleId:String) = local.getLocalArticleById(articleId)
/// 根据[articleId]从服务端获取文章详情
fun getArticleById(articleId:String) = remote.getArticleById(articleId)
/// 将文章详情[article]插入本地数据库
fun insertArticle(Article article) = local.insertArticle(article)
}
复制代码
这样的代码最大的问题是没作到关注点分离。
ViewModel层并不关心数据怎么来,也不关心数据应该怎么存储。它只关心拿到Model层的原始数据以后应该怎么将其转换为View层须要展现的数据。
基于这个原则,改造以后的代码以下:
/// ViewModel
fun getArticleDetail(articleId:String):Observable {
return repository.getArticleDetail(articleId)
.doOnSuccess{
// 数据转换成View层须要的数据
renderUI(it)
}
}
/// Model
class ArticleRepository constructor(private val remote:ArticleService,private val local:ArticleDao){
/// 获取文章详情,
///
/// 若是文章之前已被缓存过,那么直接获取缓存的数据,不然拉取服务端的数据并缓存到本地数据库
/// 返回 [Observable] 给 ViewModel层
fun getArticleDetail(articleId:String):Observable {
return local.getLocalArticleById(articleId)
.onErrorResumeNext {
remote.getArticleById(id)
.doOnSuccess { local.insertArticle(it) }
}
}
复制代码
在进行框架搭建的过程当中,我认为能尽可能减小错误的方式就是尽量的让须要调用你方法的人少写代码。
好比如下场景:
/// ViewModel
fun login() {
final token = "basic"+ base64Encode(utf8.encode('$username:$password'))
return repository.login(token)
}
/// Model
fun login(token:String){
return remote.login(token)
}
复制代码
在这种场景下,假如换成了其它的验证方式,那么全部生成token的地方都须要改,耗时耗力,并且若是说有组员生成token的方法错了,那么也挺难排查的。
所以,建议在Model层进行参数的处理
/// ViewModel
fun login() {
return repository.login(username,password)
}
/// Model
fun login(username:String,password:String){
final token = "basic"+ base64Encode(utf8.encode('$username:$password'))
return remote.login(token)
}
复制代码
另外就是返回数据的转换。
平常开发中,咱们从服务端获取到的数据并非ViewModel真正须要的,好比会出现BaseResponse<T>
这样的返回数据,而ViewModel真正须要的则是T。
在前文咱们也提到Model层的职责之一即是**提供ViewModel层须要的数据,**所以咱们须要在Repository
中对这类型的数据先处理一番。
/// ViewModel
fun getUserDetail(userId:String) = repository.getUserDetail(userId)
/// Model
fun getUserDetail(userId:String):Observable<User> {
return remote.getUserDetail(userId)
.doOnSuccess{
if(!it.success){
throw Exception(it.message)
}
}
.map{it.data}
}
//remote
@Get('user/{userId}')
fun getUserDetail(@Path("userId") userId:String):Observable<BaseResponse<User>>
复制代码
通过这番改造,明确了Model层的职责,咱们就能够将重心放在业务逻辑上,写出更加高效的代码。
关于Model的概念,我想大多数研究或学习过MVX的人都有所了解。但实际应该怎么作,怎么肯定Model的职责这个仍是看我的的积累。
我也不敢说个人写法就必定是对的,由于我所写的MVVM和其它人包括AAC都有不一样的地方,但对于我来讲,依循着这样的规范,已经给我包括团队的开发效率带来了极大的提高。
若是你对于文章中的代码有疑问或者感兴趣,能够看看我写的小专栏 《使用Kotlin构建MVVM应用程序》。
若是本文对你有帮助,请点赞支持。
==================== 分割线 ======================
若是你想了解更多关于MVVM、Flutter、响应式编程方面的知识,欢迎关注我。
简书:www.jianshu.com/u/117f1cf0c…
Github: github.com/ditclear