Spring замены. Сетевой МОК с другим Контейнером (например, Ninject)
Мне любопытно знать, возможно ли заменить Spring. Встроенный контейнер МОК сети с Ninject. Мы используем Ninject в моей команде для МОК в наших других проектах, таким образом, я хотел бы продолжить использовать тот контейнер, если это возможно.
Действительно ли это возможно? Имеет любого записанного Ninject-Spring. Сетевой адаптер??
Править
Мне нравятся много частей Spring. Сетевой пакет (доступ к данным, транзакции, и т.д.), но мне действительно не нравится контейнер внедрения зависимости. Я хотел бы заменить это Ninject
Спасибо
3 ответа
Джеффри, вы можете предоставить пример того, что вы пытаетесь сделать? Я не вижу вашу точку зрения, почему / где / Как вы хотите смешать 2 контейнера. Если ваш код полностью контейнер-агностик, то у вас не будет никаких проблем использовать либо контейнер для выполнения проводки.
Я имел в виду все, что я сказал в другом ответе. Тем не менее, я также понимаю, что если вы в настоящее время используют Spring.net в качестве сервисного локатора (то есть у вас есть код, посыпанный по всему кодовой базе, что запрашивает контейнер), этот ответ может быть не очень полезен.
Если это так, вы можете найти общий локатор обслуживания Project. Это проект с открытым исходным кодом, который пытается абстрагировать специфические сервисные локаторы, скрывая их все за общим интерфейсом.
В то время как они, похоже, не имеют никакой реализации Ninject, у них есть реализация Spring.net, поэтому, возможно, это может принять вас на полпути.
Для записи Я считаю, что Service Locator Anti-Pattern , и обнаружил, что общий сервисный локатор является неправильным ответом неверной проблеме . В моих глазах это совершенно резервный, но это может быть полезно для вас как промежуточный шаг.
Я не могу говорить конкретно о преобразовании Spring.NET в Ninject, но в целом весь код приложения должен быть написан в формате DI Container- агностик .
Лучший способ думать о контейнерах DI - это Голливудский принцип . В терминах DI это становится , не вызывайте контейнер DI, он позвонит вам .
Другими словами, лучшее применение DI - использовать простые шаблоны, такие как Constructor Injection и Abstract Factory .
Большинство достойных внимания контейнеров DI по своей сути понимают эти шаблоны, поэтому не требуется никаких специальных, специфичных для контейнера DI, прыжков через обручи.
Это также означает, что в идеале вы должны иметь только код, специфичный для контейнера DI, в одном файле вашего приложения. Это место называется Composition Root , и именно здесь контейнер DI связывает весь граф объектов и уходит с дороги.
Если вы будете следовать этому принципу, вы легко сможете обменять один контейнер DI на другой.
В следующих сообщениях есть более подробная информация: