Где реализовывать логику получения информации по апи и сохранение в дб

Например, у нас есть 2 источника данных(DataSource). Когда получаем данные из апи, их нужно проверить. И если проверка прошла успешна, выполнить еще 1 api запрос и сохранить данные в бд.

Вопрос в чем. Где реализовывать эту логику? У меня есть несколько догадок, и я хочу точно знать где я должен это делать.


1 - В data слое(в каком-то методе репозитория, делать первый запрос, проверять, делать второй и отправлять результат в бд)? Т.е выходит 1 метод в репозитории, где нужные проверки и решения происходят

Если вы не поняли что я имею ввиду, вот пример

class SomeUseCase(private val repository: Repository): Boolean {
   fun signIn(){
       return repository.signIn()
   }
}

class SomeRepositoryImpl(val apiDataSource: Api, val dbDataSource: Db): Repository {
    fun signIn(): Boolean {
      val hasApiKey = apiDataSource.HasApiKey()

       if(!hasApiKey) {
            val apiKey = apiDataSource.GetApiKey()
            dbDataSource.addApiKeyToDb(apiKey)

            return true;
       }

       return false;
    }
} 

2- Или создавать методы в репозитории(на отправку второго запроса и добавление в бд).

Получается, что будет метод отправки первого запроса в репозитории, проверка в usecase если все норм, вызов из usecase второго запроса и вызов 3его(добавление в бд)? (этот вариант кажется нелогичным, ибо в репозитории дохера не нужных методов получится, но все же есть сомнение)

Если вы не поняли вдруг, вот пример usecase

class SomeUseCase(private val repository: Repository): Boolean{
   fun signIn(){
       val hasApiKey = repository.HasApiKey()

       if(!hasApiKey) {
            val apiKey = repository.GetApiKey()
            repository.addApiKeyToDb(apiKey)

            return true;
       }

       return false;
   }
}

Какой из этих способов правильный. И вообще есть ли правильный среди них?


Ответы (1 шт):

Автор решения: Wlad

по одно из трактовок юзкейса - он не должен обладать логикой, а должен быть лишь связующим звеном между слоями Data и UI (которые в идеальнйо чистой архитектуре не знают друг про друга, но оба знают про ЮзКейс).
лично я всегда в голове пользуюсь правилом: "если я не могу заменить юзкейс опциональной переменной - это плохой юзкейс".

мне нравится 1ый вариант, потому что:

  1. у вас есть DataSource, которые занимаются всей "грязной" работой.
  2. репозиторий - это начальник, который координирует их работу.
  3. ЮзКейс - просто связующее звено.
→ Ссылка