Варианты подключения зависимостей с NInject

Question

С NInject (предпочтительно 2.0), какие опции у нас есть для подключения наших объектных зависимостей в веб-приложении?

Могут ли они быть определены в файле конфигурации XML?

Или это нужно сделать с помощью кода?

Answer 1

Существует расширение для конфигурации на основе XML: https://github.com/ninject/ninject.extensions.xml

Вы можете сделать намного более мощное связывание в коде.

Answer 2

Ninject не имеет конфигурации XML, извините, но я не могу предоставить прямую ссылку (потому что на их сайте есть флеш-элементы), но вот цитата из ninject.org :

Освободи себя от XML

Большинство других .NET инъекций зависимостей рамки разработаны вокруг использования XML для объявления привязок типов. Вместо того, чтобы заставлять вас писать громоздкий и подверженный ошибкам текст, Ninject свободно владеет оружием интерфейс, который позволяет подключить части вашего приложения, используя полноценный код. Это означает, что вы можете воспользоваться возможностями IDE и компилятор, как завершение кода и тип безопасности.

Answer 3

Проблема, которую я вижу с определением привязок только в коде, состоит в том, что вы должны добавить ссылку на dll. Вы не можете изменить привязку, не добавив ссылку на новую dll (удалив ссылку на старую), изменив код и перекомпилировав.

Если бы у нас была конфигурация xml, мне бы вообще не понадобилась ссылка, и мне не пришлось бы перекомпилировать. Прямо сейчас у меня есть приложение MVC, которое использует DI для передачи репозиториев в контроллеры. Ничто иное, как код Ninject для добавления привязок, использует конкретные реализации репозиториев. И все же мне нужно добавить ссылку на dll, содержащую свои реализации. Только для одной строки кода!

Или, может быть, есть возможность добиться этого с помощью Ninject?

Answer 4

Чего вы хотите достичь? Какие вещи вы хотите настроить? Динамический выбор стратегии? Переходя в номера портов? Вы могли бы предложить гораздо больше информации о том, что вы думаете, чтобы получить лучший ответ [который вы можете принять: P].

Вы должны разделить проблемы:

1. известный объект проводки (DI)
2. конфигурация - как правило, вы хотите разделить их на небольшие сфокусированные подмножества, например Сильно типизированные элементы конфигурации по сравнению с глобальным пулом настроек в большой куче, разбитой вместе appSettings
3. plugins / неизвестно подключение объекта (MEF?)

В первом пуле, делать это в коде - это просто правильный путь, и я не могу думать ни о каком преимуществе, которое даст XML, особенно. в контексте сильных имен и т. д.