Замените Spring.Net IoC другим контейнером (например, Ninject)

Question

Мне любопытно узнать, возможно ли заменить встроенный контейнер IoC Spring.Net на Ninject. Мы используем Ninject в моей команде для IoC в других наших проектах, поэтому я хотел бы продолжить использовать этот контейнер, если это возможно.

Возможно ли это? Кто-нибудь написал адаптер Ninject-Spring.Net ??

Редактировать

Мне нравятся многие части пакета Spring.Net (доступ к данным, транзакции и т. Д.), Но мне не очень нравится контейнер внедрения зависимостей. Я хотел бы заменить это на Ninject

Спасибо

Answer 1

Я не могу говорить конкретно о преобразовании Spring.NET в Ninject, но в целом весь код приложения должен быть написан так, чтобы он был DI-независимым от контейнера .

Лучший способ думать о DI Containers - это Голливудский принцип . С точки зрения DI, это становится, не вызывать Контейнер DI, это позвонит вам .

Другими словами, лучшее применение DI - использовать простые шаблоны, такие как Конструктор Injection и Абстрактная фабрика .

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

Это также означает, что в идеале в вашем приложении должен быть только код, специфичный для DI-контейнера, в одном файле. Это место называется Composition Root , и именно здесь DI-контейнер связывает весь граф объектов и уходит с дороги.

Если вы следуете этому принципу, вы можете легко заменить один DI-контейнер на другой.

Следующие сообщения имеют более подробную информацию:

• Где мне делать инъекцию с Ninject 2+ (и как мне расположить свои модули?)
• Дизайн - Где должны регистрироваться объекты при использовании Windsor

Answer 2

Джеффри, не могли бы вы привести пример того, что вы пытаетесь сделать? Я не вижу вашей точки зрения, почему / где / как вы хотите смешать 2 контейнера. Если ваш код полностью не зависит от контейнера, то у вас не возникнет проблем с использованием любого контейнера для подключения.

Answer 3

Я имел в виду все, что я сказал в моем другом ответе. Однако я также понимаю, что если вы в настоящее время используете Spring.NET в качестве локатора службы (т. Е. У вас разбросан код по всей базе кода, который запрашивает контейнер), этот ответ может быть не очень полезным. *

В этом случае вам может пригодиться проект Common Service Locator . Это проект с открытым исходным кодом, который пытается абстрагировать определенные сервисные локаторы, скрывая их за общим интерфейсом.

Хотя у них, похоже, нет реализации Ninject, у них есть реализация Spring.NET, так что, возможно, это приведет вас на полпути.

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