Which is better to put the Coroutine call in the Repository or the ViewModel?

Question

Just wondering others opinion I have 2 ways I can go about doing something and was curious which is better (and hopefully why you think so)

I have 2 files WordRepository and WordViewModel. I can either do the coroutines in the Repo or in the ViewModel both ways work, but hoping someone can give me a clue as to why I would do the coroutines in one or the other and vice versa.

Version A.(Where the coroutine is in the Repo)

WordRepo:

class WordRepository(private val wordDao: WordDao): WordRepo {

    @WorkerThread
    override suspend fun deleteAllLogsOlderThan(XDays: Int): Int = withContext(IO) {
        return@withContext wordDao.deleteAll()
    }

}

WordViewModel:

class WordViewModel(private val wordRepository: WordRepo) : ViewModel() {

    fun deleteAllLogsOlderThanA(XDays:Int): Int = runBlocking {
        wordRepository.deleteAllLogsOlderThan(XDays)
    }

}

Version B.(Where the coroutine is in the ViewModel)

Word Repo:
class WordRepository(private val wordDao: WordDao): WordRepo {

    @WorkerThread
    override suspend fun deleteAllLogsOlderThan(XDays: Int): Int = wordDao.deleteAll()

}

WordViewModel:
class WordViewModel(private val wordRepository: WordRepo) : ViewModel() {

    fun deleteAllLogsOlderThanA(XDays:Int): Int = runBlocking {
            withContext(IO) {
                wordRepository.deleteAllLogsOlderThan(XDays)
            }
        }

}

Answer 1

I think either way is fine honestly but if I have to choose I prefer keeping thread related code in the repository layer. (Version A in the example)

My justification:

(A) View Models should not assume how Repositories internally work. Version B implies that the View Model assumes that the Repository will run on the calling thread.

(B) Also, the repository should not depend on other components to use a specific thread to call its method. The repository should be complete by itself.

(C) To avoid code duplication. Having multiple View models calling one repository method is a very common situation. Version A wins in this case because you only need Corountine in one place, the repository.

I suggest looking at some of the Google Samples to see where they like to handle Coroutine and data access threading codes.

1. Sunflower uses Coroutine code in their repository. This is probably particularly useful for you because it includes examples of fire-and-forget type of requests.

2. GitHubBrowserRepo does not use Coroutine but the repository keeps reference to the Executor instances that are used when accessing the data.