多远程数据源下的Repository模式优化方案咨询

Hey there! Great question—this is exactly the kind of problem the Repository pattern is designed to solve when implemented with proper separation of concerns. Let's break down how to decouple your Repository from concrete data sources like Firebase Firestore and Retrofit, so swapping out providers later becomes trivial.

Step 1: Abstract Your Data Sources with Interfaces #

The core issue right now is your Repository depends directly on concrete classes (FirebaseFirestore, Retrofit service instances) instead of abstract contracts. Fix this by defining interfaces that represent the actions you need to perform, not how they're implemented.

For your use case, split the interfaces based on data responsibilities (since you have two distinct remote sources):

// Interface for user-related data operations (handled by Firebase)
interface UserDataSource {
    suspend fun getUserById(userId: String): Result<User>
    suspend fun updateUser(user: User): Result<Unit>
}

// Interface for search/complex query operations (handled by ElasticSearch)
interface SearchDataSource {
    suspend fun searchItems(query: String, filters: Map<String, String>?): Result<List<Item>>
    suspend fun getTrendingItems(): Result<List<Item>>
}

Step 2: Implement Interfaces with Concrete Data Sources #

Now create concrete classes that implement these interfaces, each wrapping your existing Firebase and Retrofit logic:

Firebase Implementation #

class FirebaseUserDataSource(private val firestore: FirebaseFirestore) : UserDataSource {
    override suspend fun getUserById(userId: String): Result<User> {
        return try {
            val document = firestore.collection("users").document(userId).get().await()
            val user = document.toObject(User::class.java) ?: throw NullPointerException("User not found")
            Result.success(user)
        } catch (e: Exception) {
            Result.failure(e)
        }
    }

    override suspend fun updateUser(user: User): Result<Unit> {
        // Firestore update logic here
    }
}

ElasticSearch/Retrofit Implementation #

class ElasticSearchSearchDataSource(private val searchApi: SearchApi) : SearchDataSource {
    override suspend fun searchItems(query: String, filters: Map<String, String>?): Result<List<Item>> {
        return try {
            val response = searchApi.search(query, filters)
            if (response.isSuccessful) {
                Result.success(response.body()?.items ?: emptyList())
            } else {
                Result.failure(IOException("Search request failed"))
            }
        } catch (e: Exception) {
            Result.failure(e)
        }
    }

    override suspend fun getTrendingItems(): Result<List<Item>> {
        // Retrofit trending items logic here
    }
}

Step 3: Make Your Repository Depend on Abstractions #

Modify your Repository to accept these interface instances in its constructor, instead of directly initializing Firebase/Retrofit objects. This way, the Repository only cares about what operations it can perform, not how they're executed.

class AppRepository(
    private val userDataSource: UserDataSource,
    private val searchDataSource: SearchDataSource
) {
    // Delegate calls to the appropriate data source
    suspend fun getUser(userId: String) = userDataSource.getUserById(userId)
    suspend fun searchItems(query: String) = searchDataSource.searchItems(query, null)
    
    // You can also add higher-level logic here (e.g., caching, combining data from sources)
    suspend fun getUserWithFavoriteItems(userId: String): Result<UserWithFavorites> {
        return userDataSource.getUserById(userId).mapCatching { user ->
            val favorites = searchDataSource.searchItems(user.favoriteTag, null).getOrThrow()
            UserWithFavorites(user, favorites)
        }
    }
}

Step 4: Use Dependency Injection (DI) to Manage Instances #

To avoid manually creating instances of your data sources and Repository (which would bring back coupling), use a DI framework like Hilt (recommended for modern Android) or Dagger. This lets you define which concrete implementation to use for each interface, and inject them wherever needed.

Here's a quick Hilt module example:

@Module
@InstallIn(SingletonComponent::class)
object DataModule {
    // Provide Firebase Firestore instance
    @Provides
    fun provideFirebaseFirestore(): FirebaseFirestore {
        return FirebaseFirestore.getInstance()
    }

    // Provide UserDataSource implementation (Firebase)
    @Provides
    fun provideUserDataSource(firestore: FirebaseFirestore): UserDataSource {
        return FirebaseUserDataSource(firestore)
    }

    // Provide Retrofit SearchApi instance
    @Provides
    fun provideSearchApi(): SearchApi {
        return Retrofit.Builder()
            .baseUrl("https://your-elasticsearch-api.com/")
            .addConverterFactory(GsonConverterFactory.create())
            .build()
            .create(SearchApi::class.java)
    }

    // Provide SearchDataSource implementation (ElasticSearch)
    @Provides
    fun provideSearchDataSource(searchApi: SearchApi): SearchDataSource {
        return ElasticSearchSearchDataSource(searchApi)
    }

    // Provide Repository instance
    @Provides
    fun provideAppRepository(
        userDataSource: UserDataSource,
        searchDataSource: SearchDataSource
    ): AppRepository {
        return AppRepository(userDataSource, searchDataSource)
    }
}

Step 5: Bonus: Add Local Data Source Abstraction (For Caching) #

If you want to add local caching later (e.g., with Room), you can follow the same pattern: define a LocalUserDataSource interface, implement it with Room, and inject it into your Repository. The Repository can then handle logic like checking local cache first, then fetching remotely if needed—all without changing Presenter code.

Why This Works #

• Loose Coupling: Your Repository and Presenter layers have zero knowledge of Firebase or ElasticSearch. They only interact with interfaces.
• Easy Swaps: If you need to replace Firebase with another backend, just create a new UserDataSource implementation and update the DI module. No changes to Repository or Presenter code required.
• Testability: You can easily mock UserDataSource or SearchDataSource in unit tests for your Repository, without needing to connect to real services.

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