Почему сетевой сервис стоит хранить как property, а не локальную переменную?

Жизненный цикл сервиса напрямую влияет на корректность асинхронной работы.

Проблема локальной переменной

Рассмотрим пример:

func loadData() {
    let service = NetworkService()
    service.fetch { result in
        // callback
    }
}

После выхода из loadData:

• service теряет все сильные ссылки

• ARC может освободить объект

• запрос может быть отменен или завершиться некорректно

Это поведение зависит от реализации сервиса, но риск всегда есть.

Почему property решает проблему

Если сервис хранится как свойство:

final class ViewModel {
    private let service = NetworkService()
}

Тогда:

• сервис живет столько же, сколько и ViewModel

• асинхронные запросы стабильны

• callback-и гарантированно дойдут

Это делает код предсказуемым и проще для отладки.

Дополнительные преимущества

Хранение сервиса как property также дает:

• повторное использование сервиса

• возможность отмены запросов

• удобство тестирования (через DI)

Когда локальная переменная допустима

Редкие случаи:

• синхронная логика

• stateless-утилиты

• фабрики без асинхронности

Для сетевых сервисов это почти никогда не подходит.

Вывод

Сетевой сервис должен жить дольше, чем метод, который его использует. Хранение сервиса как property гарантирует корректный жизненный цикл, стабильные асинхронные операции и упрощает архитектуру. Локальная переменная для сервиса — частый источник трудноуловимых багов.