Блог

Я создаю многоуровневое приложение с помощью ASP.NET Интерфейс MVC и ServiceStack.СЕТЕВЫЕ веб-службы.

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

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

На самом деле не в случае 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 действует скорее как хранилище зависимостей.

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

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

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

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

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

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

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

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