Solo me preguntaba la opinión de los demás. Tengo 2 formas en que puedo hacer algo y tenía curiosidad por saber cuál es mejor (y con suerte por qué piensas eso)
Tengo 2 archivos WordRepository y WordViewModel. Puedo hacer las corrutinas en el Repo o en ViewModel en ambos sentidos, pero espero que alguien pueda darme una pista de por qué haría las corrutinas en uno u otro y viceversa.
Versión A. (Donde está la corrutina en el 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) } }Versión B. (Donde está la corrutina en 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) } } }Sinceramente, creo que cualquier forma está bien, pero si tengo que elegir, prefiero mantener el código relacionado con el hilo en la capa del repositorio. ( Versión A en el ejemplo)
Mi justificación:
(A) Los modelos de vista no deben asumir cómo funcionan internamente los repositorios. La versión B implica que el modelo de vista asume que el repositorio se ejecutará en el subproceso de llamada.
(B) Además, el repositorio no debe depender de otros componentes para usar un hilo específico para llamar a su método. El repositorio debe estar completo por sí mismo.
(C) Para evitar la duplicación de código. Tener varios modelos de vista llamando a un método de repositorio es una situación muy común. La versión A gana en este caso porque solo necesita Corountine en un lugar, el repositorio.
Sugiero mirar algunos de los ejemplos de Google para ver dónde les gusta manejar Coroutine y los códigos de subprocesamiento de acceso a datos.
Sunflower usa el código Coroutine en su repositorio. Esto probablemente sea particularmente útil para usted porque incluye ejemplos del tipo de solicitudes de disparar y olvidar.
GitHubBrowserRepo no usa Coroutine pero el repositorio mantiene una referencia a las instancias de Executor que se usan al acceder a los datos.
La pregunta es dónde especificar que los trabajos del repositorio deben ejecutarse en grupos de subprocesos de IO:
Francamente, no estoy seguro de qué manera es mejor.
B) Tenerlo en ViewModel significa más transparencia de lo que se ejecuta en qué subproceso. Esta es también la forma en que trabajé principalmente con RxJava. Como aspecto negativo, su ViewModel estará abarrotado de cambios de subprocesos (withContext()), mientras que en realidad es obvio que todo el trabajo del repositorio debe ejecutarse en el subproceso de fondo. Entonces, ¿es útil esta información adicional?
R) Tenerlo en el Repositorio significa más flexibilidad con respecto al cambio de subprocesos en el repositorio y un código más limpio en ViewModel. El código será menos explícito desde el punto de vista de ViewModel sobre los hilos. Como negativo, todos los métodos de repositorio deberán suspenderse, por lo que solo se pueden usar desde coroutines.