Есть ли проблема с наличием более одного контейнера IoC в решении?

Question

Я создаю многоуровневое приложение с интерфейсом ASP.NET MVC и веб-службами ServiceStack.NET.

Я начал использовать Ninject для DI в начале проекта. Теперь, когда я добавляю ServiceStack в микс, мне любопытно, есть ли потенциал для будущих проблем:

Библиотека ServiceStack по умолчанию использует Funq в качестве контейнера IoC. Кажется, все работает нормально, но мне интересно, увижу ли я какие-либо проблемы с наличием двух контейнеров IoC в одном приложении?

Answer 1

Не совсем в случае Funq (который используется в ServiceStack) в качестве статически связанного IOC, который больше похож на словарь C #, полный кешированных делегатов конструктора, чем на полнофункциональный IOC.Он включен в исходную форму в ServiceStack и был выбран потому, что он очень быстрый (т. Е. Близок к собственным скоростям): http://www.codeproject.com/Articles/43296/Introduction-to-Munq-IOC-Container-for-ASP-NET.aspx

Регистрация в Funq неинвазивна, т. Е. Вы должны вручную зарегистрировать свои зависимости, так какне сканирует все ваши сборки без разбора, регистрируя все найденные зависимости.Если вы решите не использовать Funq и использовать другой IOC, внедрив IContainerAdapter и делегировав его в другой IOC, то ваши словари Funq для кэшированных делегатов будут пустыми (т. Е. Отсутствует кеш), и ServiceStack просто спросит ваш предпочитаемый IOC.вместо зависимости.

Единственное, что нужно иметь в виду, это то, что сами веб-сервисы регистрируются и автоматически подключаются ServiceStack, а не вашим предпочтительным контейнером IOC, поэтому в этом случае ваш IOC действует скорее как хранилище.зависимостей.

Answer 2

Я бы сказал - это зависит.

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

Если все ваши зависимости являются временными или созданы с помощью пользовательских методов фабрики, то вы, вероятно, будете в порядке. Тем не менее, все может стать непредсказуемым, если вы начнете пытаться бросать в микс синглтоны или зависимости «экземпляр на веб-запрос».

Я никогда раньше не использовал Funq, но если это способный контейнер IoC, я бы порекомендовал удалить Ninject из вашего проекта, если это возможно. Помимо устранения вероятности того, что ваше приложение будет трудно отслеживать, оно сделает ваш код более СУХИМЫМ и последовательным.

Answer 3

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

В целом, я думаю, что согласованность улучшаетсякачество, поэтому я хотел бы рассмотреть возможность рефакторинга кода для использования одного поставщика.Я использую Ninject и у меня есть 4 модуля для инъекций сервисов и репозиториев.Каждый модуль содержит 10-20 подпрограмм впрыска - я могу реорганизовать их в течение часа.Если ваш проект имеет аналогичный размер, то проведите рефакторинг и используйте один IoC.

Edit Я никогда не использовал ServiceStack.Net, но насколько ваш проект зависит от этого фреймворка / инструментария?Вы вероятно замените это чем-то другим в ближайшем будущем?Насколько это зависит от вашего проекта MVC?Я пытаюсь придумать сценарий, в котором стоимость обслуживания одного IoC будет выше стоимости обслуживания другого IoC.

Глядя на Ninject, есть расширение Ninject и Ninject MVC 3.Расширение упрощает работу и не конфликтует ни с чем другим.В моем случае мне пришлось заменить стандартный Ninject на Ninject MVC 3, потому что для меня он делал все, что делала стандартная версия (+ дополнительная), и был проще в настройке.