Service Locator — развенчивание мифов

[@lair]

Разница в том, что каждый раз, запрашивая у локатора сервисов экземпляр заданного типа, Вы будете получать снова и снова тот же самый экземпляр, который сохраняет в себе уже использованные данные.

Простите, а из какого определения сервис-локатора вы это взяли?

PS

паттерн Локатор сервисов, который весьма популярен в .Net, и имеет плохую репутацию в iOS.

Вообще-то, в .Net он тоже считается антипаттерном.

[@Demtriy]

Вы дали ссылку, которая уже содержится в статье.

[@lair]

И что это меняет?

[@Demtriy]

Разумеется. Только Вы, как автор сервиса, можете ответить на вопрос, нужно ли это делать. Любые формы пассивизации лучше чем хранение данных в оперативной памяти. Но тут Вам нужно учесть накладные расходы — не будет ли это затратно по времени, или не будет ли это трудоемко по сопровождению. К примеру, если Вам нужно обслуживать профиль пользователя, то не обязательно сохранять его в CoreData. Но, для списков или объектов, которые должны быть доступны между сессиями — пассивизация и восстановление — предпочтительней, чем загрузка из сети и использование в виде сервисов. Локатор сервисов — это не серебряная пуля. Он удобен, но не может покрыть весь скоп задач мобильной разработки.

[@necrosoft]

Спасибо за статью, у меня в приложении есть несколько сервисов и синглтонов, есть аналог координатора — синглтон Router который отвечает за работу таб бара, navigation controller-ов и так далее, вот думаю теперь стоит ли это все добавить «под крыло» локатора, вот только думаю а надо ли, впереди маячит задача с несколькими пользователями и User сейчас сделан как синглтон, других плюсов чтобы осуществлять рефакторинг пока не вижу, и не знаю надо ли оно. Но статья хорошая, теперь хоть стало понятно что это такое.