Где будешь писать работу с сетевыми запросами?

Архитектурный подход к работе с сетевыми запросами

Работа с сетевыми запросами в современных Android приложениях требует тщательного планирования и выбора правильного архитектурного слоя. Как эксперт с 10+ лет опыта, я не рекомендую размещать сетевую логику непосредственно в Activity, Fragment или даже ViewModel. Вместо этого следует использовать принципы чистой архитектуры и разделения ответственности.

Выбор слоя: Repository и UseCase

Основное место для сетевых операций — это Repository (репозиторий) в слое данных. Этот паттерн из Domain-Driven Design прекрасно адаптируется под задачи Android.

// Пример Repository для работы с сетевыми запросами
class UserRepository(
    private val userApiService: UserApiService,
    private val localDataSource: UserLocalDataSource
) {
    suspend fun getUser(id: String): Result<User> {
        // 1. Проверяем локальные данные (оптимизация)
        val localUser = localDataSource.getUser(id)
        if (localUser != null) {
            return Result.Success(localUser)
        }
        
        // 2. Выполняем сетевый запрос
        try {
            val remoteUser = userApiService.getUser(id)
            // 3. Сохраняем в локальное хранилище
            localDataSource.saveUser(remoteUser)
            return Result.Success(remoteUser)
        } catch (e: Exception) {
            return Result.Error(e)
        }
    }
}

Ключевые принципы организации

• Слой Data: Здесь размещаются все Repository, которые абстрагируют источник данных (сеть, база данных, файлы).
• Слой Domain: Для сложной бизнес-логики можно создать UseCase/Interactor, которые используют Repository.
• Инверсия зависимостей: Repository получает API-клиент через конструктор, что позволяет легко тестировать и заменять реализации.

Практическая реализация

В реальном проекте структура выглядит так:

1. Создание API-клиента (обычно в отдельном модуле network)

   // Модуль для сетевых взаимодействий
   object NetworkModule {
       fun provideUserApiService(): UserApiService {
           return Retrofit.Builder()
               .baseUrl("https://api.example.com/")
               .addConverterFactory(MoshiConverterFactory.create())
               .build()
               .create(UserApiService::class.java)
       }
   }
   

2. Repository как единственный источник данных

   // Repository скрывает детали источника данных
   interface UserRepository {
       suspend fun getUser(id: String): Result<User>
       suspend fun updateUser(user: User): Result<Unit>
   }
   

3. ViewModel использует Repository через UseCase

   class UserViewModel(
       private val getUserUseCase: GetUserUseCase
   ) : ViewModel() {
       private val _userState = MutableStateFlow<UserState>(UserState.Loading)
       val userState: StateFlow<UserState> = _userState
       
       fun loadUser(id: String) {
           viewModelScope.launch {
               getUserUseCase.execute(id).collect { result ->
                   _userState.value = result.toUserState()
               }
           }
       }
   }
   

Преимущества такого подхода

• Тестируемость: Repository легко тестировать с mock API-клиентами
• Замена источников: Можно переключиться с сети на локальные данные без изменения бизнес-логики
• Контроль состояния: Централизованная обработка ошибок, загрузки и кэширования
• Многопоточность: Все сетевые операции выполняются в корутинах, управляемых из ViewModel

Никогда не делайте сетевые запросы напрямую в UI-компонентах! Это нарушает принципы SOLID, делает код непроверяемым и приводит к проблемам с жизненными циклами компонентов Android. Современные архитектурные подходы (Clean Architecture, MVI, MVVM) четко определяют Repository как единственное правильное место для сетевых взаимодействий.