Введение контейнера IoC в устаревший код

Question

Я пишу новую библиотеку .NET для внутреннего использования в моей компании, которая будет использовать IoC через Dependency Injection. Естественно, эту библиотеку будет намного проще использовать, если мы будем использовать контейнер IoC для разрешения экземпляров.

Однако код, который будет выполнять вызовы в эту библиотеку, в настоящее время НЕ использует никакого внедрения зависимостей, и рефакторинг старого кода для использования DI выходит за рамки моего проекта. Итак, как лучше всего начать использовать контейнер в этом устаревшем коде для получения экземпляров из моей новой библиотеки?

Если возможно, я бы хотел не засорять указанный устаревший код жесткими ссылками на тот контейнер IoC, который я выбрал. Поскольку я относительно новичок в DI, вполне вероятно, что мы в какой-то момент передумаем, какой контейнер мы хотим использовать.

Если я оберну свой контейнер чем-то вроде библиотеки CommonServiceLocator в CodePlex, это будет разумным подходом?

Что сделали другие люди?

Answer 1

Вы можете использовать шаблон фасада / прокси, чтобы скрыть DI-контейнер от вашего старого контейнера. По сути, вы подключаете свое наследие к пользовательскому классу, который вы реализуете, который будет знать о контейнере DI. Теперь, если вы изменяете свой DI, вы обновляете свои фасады, а не устаревший код.

Я не проводил много исследований Common Service Locator, но это может быть хорошим решением. Возможно, вы захотите привязать свой фасад к CSL, это полностью скроет концепцию DI от вашего старого кода.

Answer 2

Насколько я понимаю, вы хотите вызвать код с поддержкой DI из устаревшего кода.

Лучший вариант - сохранить новую библиотеку DI Friendly, но не зависит от контейнера .

Делая это, вы можете предоставить простой Фасад, который может использовать старый код. Нет необходимости, чтобы унаследованное приложение использовало какой-либо DI-контейнер, и нет необходимости в Common Service Locator.