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

Question

Если сервис создается как локальная переменная, он может быть деаллоцирован сразу после выхода из метода. Это приведет к отмене запросов или потере callback-ов. Хранение сервиса как property гарантирует, что он живет столько же, сколько и владеющий объект. Это делает асинхронные операции предсказуемыми. Такой подход является стандартной практикой.

YeaHub · Accepted Answer

Жизненный цикл сервиса напрямую влияет на корректность асинхронной работы.Проблема локальной переменнойРассмотрим пример: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 гарантирует корректный жизненный цикл, стабильные асинхронные операции и упрощает архитектуру. Локальная переменная для сервиса — частый источник трудноуловимых багов.