2009-11-09 4 views
12

Архитектура модуля NInject кажется полезной, но я волнуюсь, что она немного запутается.Как вы организуете свои модули NInject?

Как вы организуете свои модули? На какой сборке вы их держите и как вы решаете, какие проводки идут в каком модуле?

+0

Хороший вопрос. Я хотел бы больше обсудить это, поскольку я разделяю ваши проблемы. Наличие одного модуля в подсистеме звучит разумно, но у меня также есть модули для подключения зависимостей по-разному для Unit Testing. – JulianM

ответ

7

Каждая подсистема получает модуль. Конечно, определение того, что гарантирует категоризацию как «подсистема», зависит от ...

В некоторых случаях ответственность за некоторые привязки повышается до более высокого уровня, поскольку подсистема/компонент нижнего уровня не в состоянии сделать окончательное авторитетное решение - в некоторых случаях это может быть достигнуто путем передачи параметров в модуль.

2

Ответ на свой пост после нескольких лет использования NInject.

Вот как я организую свои NInjectModules, используя книжный магазин в качестве примера:

  • BookStoreSolution
    • Domain.csproj
    • Services.csproj
      • CustomerServicesInjectionModule.cs
      • PaymentProcessingInjectionModule.cs
    • DataAccess.csproj
      • CustomerDatabaseInjectionModule.cs
      • BookDatabaseInjectionModule.cs
    • CustomSecurityFramework.csproj
      • CustomSecurityFrameworkInjectionModule.cs
    • PublicWebsite.csproj
      • PublicWebsiteInjectionModule.cs
    • Intranet.csproj
      • IntranetInjectionModule.cs

Что это говорит, что каждый проект в системе поставляется расфасованный с одним или несколькими Модули NInject, которые знают, как настроить привязки для классов этого проекта.

В большинстве случаев отдельное приложение не хочет вносить существенные изменения в модули ввода по умолчанию, предоставляемые проектом. Например, если я создаю небольшое приложение WinForm, которое должно импортировать проект DataAccess, обычно мне также захочется, чтобы все классы проекта Replaceitory <> привязаны к связанным с ними интерфейсам IRepository <>.

В то же время нет ничего, что вынуждало бы отдельное приложение использовать специальный модуль инъекции.Приложение может создать свой собственный модуль впрыска и игнорировать модули по умолчанию, предоставляемые проектом, который он импортирует. Таким образом, система по-прежнему остается гибкой и развязанной.

+0

Итак ... это означает, что вам нужно включить пакет Ninject/reference в каждый из проектов, имеющих модуль ??? Я предпочел бы иметь одно место в моей сборке вызовов (например, веб-проект), где я регистрирую каждую необходимую мне услугу, и тогда только эта сборка будет напрямую ссылаться на Ninject. Мысли? –

+0

Да, это недостаток этой настройки. Однако, если у вас нет очень чистого приложения, которое никогда не использует вложение свойств или не использует Kernel.Get <>(), тогда я обычно получаю ссылку на NInject. – cbp

+0

ну ... я только что закончил проект, который использовал Unity для DI, и я закончил с одним длинным методом RegisterServices в моем загрузчике в веб-проекте. Ни один проект моего класса не имел прямой зависимости от Unity или EntLib напрямую. Все они использовали инъекцию конструктора. Я думал, что это довольно хорошо. –

Смежные вопросы