Варианты подключения зависимостей с NInject
С NInject (предпочтительно 2.0), какие варианты у нас есть для подключения наших объектных зависимостей в веб-приложении?
Могут ли они быть определены в файле конфигурации XML?
Или это должно быть сделано с помощью кода?
4 ответа
У Ninject нет конфигурации XML, извините, но я не могу предоставить прямую ссылку (потому что на их сайте есть flash-элементы), но вот цитата из http://ninject.org/:
Освободи себя от XML
Большинство других.NET-структур для внедрения зависимостей разработаны с использованием XML для объявления привязок типов. Вместо того, чтобы заставлять вас писать громоздкий и подверженный ошибкам текст, Ninject вооружает вас свободным интерфейсом, который позволяет вам соединять части вашего приложения, используя полноценный код. Это означает, что вы можете воспользоваться преимуществами IDE и компилятора, такими как завершение кода и безопасность типов.
Существует расширение для конфигурации на основе XML: https://github.com/ninject/ninject.extensions.xml
Вы можете сделать намного более мощное связывание в коде.
Проблема, которую я вижу с определением привязок только в коде, состоит в том, что вы должны добавить ссылку на dll. Вы не можете изменить привязку, не добавив ссылку на новую dll (удалив ссылку на старую), изменив код и перекомпилировав.
Если бы у нас была конфигурация xml, мне бы вообще не понадобилась ссылка, и мне не пришлось бы перекомпилировать. Прямо сейчас у меня есть приложение MVC, которое использует DI для передачи репозиториев в контроллеры. Ничто иное, как код Ninject для добавления привязок, использует конкретные реализации репозиториев. И все же мне нужно добавить ссылку на dll, содержащую свои реализации. Только для одной строки кода!
Или, может быть, есть возможность добиться этого с помощью Ninject?
Чего вы хотите достичь? Какие вещи вы хотите настроить? Динамический выбор стратегии? Переходя в номера портов? Вы могли бы предложить гораздо больше информации о том, что вы думаете, чтобы получить лучший ответ [который вы можете принять:P].
Вы должны разделить проблемы:
- известный объект проводки (DI)
- конфигурация - как правило, вы хотите разделить их на небольшие сфокусированные подмножества, например, строго типизированные элементы конфигурации и глобальный пул настроек в большой куче, смешанной а-ля
appSettings
- плагины / неизвестный объект проводки (MEF?)
В первом пуле делать это в коде - это просто правильный путь, и я не могу думать ни о каком преимуществе, которое даст XML, особенно. в контексте сильных имен и т. д.