Я часто читал, что Сервис-локаторы в IOC являются анти-шаблонами.
В прошлом году мы внедрили IOC (Ninject специально) в наше приложение на работе. Приложение является наследием, оно очень большое и фрагментировано. Существует множество способов создания класса или цепочки классов. Некоторые из них созданы веб-каркасом (который является обычным), некоторые из них создаются nHibernate. Лоты просто разбросаны по странным местам.
Как мы будем обрабатывать разные сценарии и не придумывать что-то, что не является, по крайней мере, ServiceLocatorish и не заканчиваться разными ядрами в разных местах (важны такие области, как singleton, HttpRequest и thread).
Изменить. Я добавлю немного более подробную информацию о том, что привело нас к нашему текущему шаблону SL.
На самом деле нам не нужны несколько ядер. Мы просто хотим одного (и действительно, из-за SL мы имеем только один статический). Вот наша настройка:
1) У нас есть модули Ninject в 7-8 разных проектах/сборках. Когда наше приложение (webapp) запускает модули, они собираются с помощью сканирования сборок и загружаются в ядро и помещаются в Service Locator. Так что все это довольно дорого.
2) У нас есть пользовательский интерфейс, который строится счастливым. Подумайте о 120 табличных формах, каждая из которых построит 1-10 вкладки в качестве части их жизненного цикла. SL стратегически используется в 5-6 местах, которые охватывают все это либо как чистое разрешение, либо вводятся только после введения свойств свойств.
3) Все, что связано с пользовательским интерфейсом, не покрывается этими вызовами верхнего уровня, и если эти классы хотят использовать МОК, им необходимо разработать свою собственную стратегию. Существуют разные разные рамки, каждая из которых имеет свои собственные маленькие миры.
Итак, идеальный способ сделать это из того, что я прочитал, - это инъекция ядра всякий раз, когда вам нужно получить доступ к IOC... хорошо, что все хорошо и хорошо; мы сохраняем использование SL до минимума.
Но откуда я получаю это ядро? Я не хочу создавать и регистрировать новую повсюду. Похоже, мне пришлось бы вытащить его из статического контекста или factory, чтобы я мог гарантировать, что ядро, которое я использую, держится за те же объекты с областью, что все остальные используют, а также во избежание расходов на регистрацию всех модулей. В этот момент, что бы это ни было, похоже, похоже на "Локатор сервисов"?
Имейте в виду, что это приложение ОГРОМНОЕ и тесно связанное. У нас нет роскоши потратить несколько месяцев на то, чтобы реорганизовать это. SL казался хорошим способом для нас медленно работать МОК, где мы могли, как мы успели.
