2014-09-03 4 views
2

Я использую Ninject в качестве контейнера IoC для своего приложения ASP.NET MVC. То, что я сейчас делаю, у меня есть следующие слои в моем проекте:Ninject - определить отображение в файле web.config

  • Основной
  • Фабрика
  • Инфраструктура
  • Logic
  • UI (ASP.NET MVC)

Инфраструктура, логика и пользовательский интерфейс имеют ссылки на Core и Factory имеют ссылки на все.

Когда приложение ASP.NET загружается, я вызываю метод на моей фабрике и передаю ему значение перечисления, которое сообщает ему, кто его запускает (пользовательский интерфейс или любой другой эквивалентный уровень пользовательского интерфейса), например, я бы хотел, чтобы пользовательский интерфейс работал против Классы кэша и проект Backoffice, чтобы пропустить реализацию кэша интерфейса и работать непосредственно с базой данных). Затем метод проверяет перечисление и делает соответствующее преобразование в Ninject.

Прежде всего, что я здесь делаю, это хорошая практика? каждый слой не знает слой рядом с ним, и поэтому слабо связан. Но, с другой стороны, завод имеет ссылки на все слои, что делает его плотно связанным.

Second, мои сопоставления жестко закодированы в моем слое Factory - то, что я хотел бы иметь, это сопоставления в файле .config (web.config) - это возможно?

Благодаря

ответ

1

Неизбежно, Ваше решение будет всегда иметь по крайней мере один проект, все остальное зависит от. В противном случае вы можете просто разбить вещи на отдельные решения, потому что у вас будут совершенно отдельные приложения. Цель заключается в устранении дублирования и создании областей ответственности; зависимостей.

Что касается конфигурации Ninject, существует поддержка XML-конфигурации. К сожалению, документы плохо разработаны и не допускают глубокого связывания, поэтому я не могу просто дать вам URL-адрес, чтобы перейти. Однако, если вы перейдете на http://www.ninject.org/wiki.html, а слева разверните заголовок «Ninject», затем «Использование Ninject» и, наконец, «Xml Configuration», вы получите необходимую информацию.

0

Обычно необходимо работать с composition roots. Корень композиции (как правило, пользовательский интерфейс) определяет, какие привязки (сопоставления) используются и запускает объектный граф за один раз (ну .. не всегда выполнимо, но цель должна быть как можно ближе к этому идеалу).

Если вы правильно поняли, вы заменили несколько корней композиций, указав фабрику с параметрами «enum». Наверное, поэтому существует один экземпляр/слой, отвечающий за сопоставления. Альтернативой (предпочтительной?) Является перенос этого в корень композиции, где вам не понадобится «switch (enum)». Чтобы уменьшить дублирование кода, поместите общие привязки в отдельный сбор или конфигурационный файл, который вы повторно используете. Вы также можете посмотреть в NinjectModule's, который поможет вам в этом.

Что касается конфигурации ninject по XML, я бы рекомендовал против этого. Это гораздо более хрупкое (переименование и т. П.). Делайте это только в том случае, если у вас есть сопоставления, которые вам нужно изменить после реализации. Однако для большинства проблем с конфигурацией вполне возможно (и рекомендуется) сделать это по-другому.Например:

конфигурационный файл:

DatabaseProvider = MicrosoftSQL // OracleSQL if you want to use Oracle DB... 

Ninject переплетом

Bind<IDatabaseProvider>().To<MicrosoftSqlDatabaseProvider>() 
    .When(x => config.DatabaseProvier == "MicrosoftSQL"); 
Bind<IDatabaseProvider>().To<OracleSqlDtabaseProvider>() 
    .When(x => config.DatabaseProvier == "OracleSQL"); 
Смежные вопросы