Комментарии 7
Разница в том, что каждый раз, запрашивая у локатора сервисов экземпляр заданного типа, Вы будете получать снова и снова тот же самый экземпляр, который сохраняет в себе уже использованные данные.
Простите, а из какого определения сервис-локатора вы это взяли?
PS
паттерн Локатор сервисов, который весьма популярен в .Net, и имеет плохую репутацию в iOS.
Вообще-то, в .Net он тоже считается антипаттерном.
НЛО прилетело и опубликовало эту надпись здесь
Разумеется. Только Вы, как автор сервиса, можете ответить на вопрос, нужно ли это делать. Любые формы пассивизации лучше чем хранение данных в оперативной памяти. Но тут Вам нужно учесть накладные расходы — не будет ли это затратно по времени, или не будет ли это трудоемко по сопровождению. К примеру, если Вам нужно обслуживать профиль пользователя, то не обязательно сохранять его в CoreData. Но, для списков или объектов, которые должны быть доступны между сессиями — пассивизация и восстановление — предпочтительней, чем загрузка из сети и использование в виде сервисов. Локатор сервисов — это не серебряная пуля. Он удобен, но не может покрыть весь скоп задач мобильной разработки.
Спасибо за статью, у меня в приложении есть несколько сервисов и синглтонов, есть аналог координатора — синглтон Router который отвечает за работу таб бара, navigation controller-ов и так далее, вот думаю теперь стоит ли это все добавить «под крыло» локатора, вот только думаю а надо ли, впереди маячит задача с несколькими пользователями и User сейчас сделан как синглтон, других плюсов чтобы осуществлять рефакторинг пока не вижу, и не знаю надо ли оно. Но статья хорошая, теперь хоть стало понятно что это такое.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Service Locator — развенчивание мифов