Избегание антипаттерна Service Locator с устаревшим приложением, не предназначенным для IOC

Я часто читал, что локаторы служб в IOC являются анти-шаблоном .

В прошлом году мы представили IOC (конкретно Ninject) нашему приложению на работе. Приложение унаследованное, оно очень большое и фрагментированное. Есть много способов создать класс или цепочку классов. Некоторые из них создаются веб-фреймворком (который настраивается), некоторые создаются nHibernate. Многие просто разбросаны по странным местам.

Как бы мы справились с различными сценариями и не придумали бы что-то, что не относится, по крайней мере, к ServiceLocatorish и не привело бы к различным ядрам в разных местах (важны такие области, как singleton, HttpRequest и thread).

Править Я добавлю немного больше деталей к тому, что привело нас к нашему текущему паттерну SL.

На самом деле мы не хотим нескольких ядер. Нам просто нужен один (и действительно, из-за SL у нас есть только один статический). Вот наша установка:

1) У нас есть модули Ninject в 7-8 различных проектах / сборках. Когда наше приложение (веб-приложение) запускается, модули собираются путем сканирования сборки, загружаются в ядро ​​и помещаются в Service Locator. Так что все это довольно дорого.

2) У нас есть настраиваемая структура пользовательского интерфейса, которая хорошо конструируется. Представьте себе около 120 форм с вкладками, каждая из которых создает от 1 до 10 страниц с вкладками как часть своего жизненного цикла. SL стратегически используется в 5-6 местах, которые охватывают все это либо как чистое разрешение, либо только для добавления свойств после создания экземпляра.

3) Все, что находится под пользовательским интерфейсом, не покрывается этими вызовами верхнего уровня, и если эти классы хотят чтобы использовать МОК, им нужно придумать свою собственную стратегию. Существуют различные маленькие фреймворки, каждая из которых представляет собой свои маленькие миры.

Итак, идеальный способ сделать это из того, что я прочитал, - это внедрить ядро ​​всякий раз, когда вам нужно получить доступ к IOC ... ну, это все хорошо; мы действительно сводим использование SL к минимуму.

Но откуда мне это ядро? Не хочу везде строить и регистрировать новый. Похоже, мне пришлось бы вытащить его из статического контекста или фабрики, чтобы я мог гарантировать, что ядро, которое я использую, удерживает те же объекты с областью видимости, что и все остальные, а также чтобы избежать расходов на регистрацию всех модули. В этот момент, что бы это ни было, похоже, очень похоже на локатор служб, верно?

Помните также, что это приложение ОГРОМНОЕ и тесно связано. У нас нет возможности потратить несколько месяцев на его рефакторинг. SL казался нам хорошим способом медленно работать с IOC там, где мы могли, поскольку у нас было время.