MVVM架构中Firestore SnapshotListener的最佳放置位置

最佳实践是将SnapshotListener放在Repository层，ViewModel仅负责处理业务逻辑和暴露UI所需的状态，不直接操作数据源。以下是具体原因和修正方案：

为什么选Repository层？ #

• 单一职责：Repository专注于数据获取、监听和处理，ViewModel专注于业务逻辑与UI状态映射，职责划分清晰。
• 可复用性：监听逻辑可被多个ViewModel共享，避免重复代码。
• 生命周期管控：可通过ViewModel的onCleared()回调通知Repository解绑Listener，防止内存泄漏。
• 测试友好：Repository层的数据源逻辑更容易Mock，降低单元测试复杂度。

你现有代码的问题 #

1. 异步结果传递错误：SnapshotListener是异步执行的，直接return hm无法获取异步回调中的结果，必须用LiveData传递数据。
2. 类型不匹配：函数声明返回HashMap<String, MutableList<DepotModel>>，但内部创建的是HashMap<DocumentChange.Type, MutableList<DepotModel3>>，类型不一致。
3. 无解绑逻辑：未实现Listener的移除逻辑，长期驻留会导致内存泄漏。

修正后的代码示例 #

1. Repository层：处理监听并通过LiveData传递结果 #

class DepotRepository {
    private val firebaseFirestore = FirebaseFirestore.getInstance()
    private var depotListenerRegistration: ListenerRegistration? = null
    // 用LiveData暴露数据变更，自定义密封类区分变更类型
    private val _depotChanges = MutableLiveData<Result<DepotChange>>()
    val depotChanges: LiveData<Result<DepotChange>> = _depotChanges

    // 密封类封装不同类型的文档变更
    sealed class DepotChange {
        data class Added(val depots: List<DepotModel>) : DepotChange()
        data class Modified(val depots: List<DepotModel>) : DepotChange()
        data class Removed(val depots: List<DepotModel>) : DepotChange()
    }

    fun startSnapshotListener() {
        currentUser?.let { user ->
            if (depotListenerRegistration == null) {
                depotListenerRegistration = firebaseFirestore
                    .collection("Example")
                    .document("example2")
                    .collection("Example3")
                    .addSnapshotListener { querySnapshot, error ->
                        if (error != null) {
                            _depotChanges.postValue(Result.failure(error))
                            return@addSnapshotListener
                        }

                        querySnapshot?.let { snapshot ->
                            val addedDepots = mutableListOf<DepotModel>()
                            val modifiedDepots = mutableListOf<DepotModel>()
                            val removedDepots = mutableListOf<DepotModel>()

                            snapshot.documentChanges.forEach { docChange ->
                                val depot = docChange.document.toObject(DepotModel::class.java)
                                when (docChange.type) {
                                    DocumentChange.Type.ADDED -> addedDepots.add(depot)
                                    DocumentChange.Type.MODIFIED -> modifiedDepots.add(depot)
                                    DocumentChange.Type.REMOVED -> removedDepots.add(depot)
                                }
                            }

                            // 分类型发送变更通知
                            if (addedDepots.isNotEmpty()) {
                                _depotChanges.postValue(Result.success(DepotChange.Added(addedDepots)))
                            }
                            if (modifiedDepots.isNotEmpty()) {
                                _depotChanges.postValue(Result.success(DepotChange.Modified(modifiedDepots)))
                            }
                            if (removedDepots.isNotEmpty()) {
                                _depotChanges.postValue(Result.success(DepotChange.Removed(removedDepots)))
                            }
                        }
                    }
            }
        }
    }

    // 解绑Listener，避免内存泄漏
    fun stopSnapshotListener() {
        depotListenerRegistration?.remove()
        depotListenerRegistration = null
    }
}

2. ViewModel层：监听Repository的LiveData并处理业务逻辑 #

class DepotViewModel(private val repository: DepotRepository) : ViewModel() {
    // 暴露给UI层的变更数据
    val depotChanges = repository.depotChanges

    init {
        // 初始化时启动监听
        repository.startSnapshotListener()
    }

    override fun onCleared() {
        super.onCleared()
        // ViewModel销毁时停止监听
        repository.stopSnapshotListener()
    }

    // 处理业务逻辑，根据变更类型更新UI状态
    fun handleDepotChange(change: DepotRepository.DepotChange) {
        when (change) {
            is DepotRepository.DepotChange.Added -> {
                // 处理新增逻辑，比如添加到列表
            }
            is DepotRepository.DepotChange.Modified -> {
                // 处理修改逻辑，比如更新列表项
            }
            is DepotRepository.DepotChange.Removed -> {
                // 处理删除逻辑，比如从列表移除
            }
        }
    }
}

总结流程 #

1. Repository启动Firestore监听，将异步变更通过LiveData传递。
2. ViewModel在初始化时触发监听，销毁时解绑监听。
3. UI层观察ViewModel的LiveData，根据变更更新界面，完全不接触数据源逻辑。

内容的提问来源于stack exchange，提问作者Sasuke