ASP MVC и Ninject или другой ioc. Как правильно использовать, организовать структуру?
Всем привет. Не могу понять правильный принцип использования Ninject в MVC. Сразу оговорюсь что я только учусь и возможно вообще все понял не правильно. Пишут и говорят что нужно делать по феншую (правильно) а именно разделять сборки проекта на слои и чтоб эти слои зависели от интерфесов.
Например:
1. Слой Infrastructure.Domain (интерфейсы всякие IEntity, IUnitOfWork, IQueryFactory)
2. Слой Domain (Сущности проекта (User, Role, News, Comment ) + реализация пару интерфейсов из 1)
3. Слой Domain.EF (реализация интерфейсов из 1 под орм Entity Framework)
4. Слой WebUI (собственно сам framework mvc)
Как понимаю последний слой должен сависеть только от интерфейсов Infrastructure.Domain ну еще мож от Domain (там сущности)... а вот реализацию остальных интерфесов нужно сделать через ninject. Но получается что сам ninject используется в mvc и чтоб он видел реализацию нужно подключать сборку Domain.EF. В итоги слой mvc зависит от всех остальных слоев так как нужно их указать ninject. Как правильно организовать все это дело? Какая у вас в проектах структура слоев, сборок (типичная)? Как с ними работать через ioc контейнер?
п.с так как и ioc контейнеры могут использоватся разные может создать слой чисто под использование их, есть какие идеи или это не правильно?
Не могу понят смысл ninject если можно сделать свой класс откуда по запросу будут выдаватся нужные реализации. Если при смене реализации интерфейса всеровно нужно будет удалять сборку из mvc, подключать новую и править ninject
@kid-programmer как раз для таких случаев хорошо подходит Unity. Он позволяет прописывать зависимости в xml формате в конфигурационных файлах.
Кстати я тоже заинтересован в ответе на поставленный в этой теме вопрос. Удалось что-либо выяснить?
Спасибо. У меня эта книга есть в бумажном варианте. Там описывается стандартный подход использования ninject. Но опять же чтоб указать ninject каким интерфейсам соответсвует реализация в сам проект mvc нужно подключать все сборки...
Ninject полезен в больших проектах, где присутствует сильная связанность к конкретной реализации. Т.е. если в какое то время вам нужно будет заменить какой то класс то вам не придется править зависимой код (а таких мест может быть много), модули связаны с интерфейсами которые вы связываете с конкретными реализациями в DependencyResolver'е.
Если нужно поменять реализацию какого то класса, вам нужно будет поменять связь интерфейса с конечной реализацией класса в одном месте DependencyResolver'а.
В результате в вашем коде не должно остаться записей создания объектов, только их интерфейсы.
А на счет подключения/удаления сборок - это уже другая тема. Суть использования ninject к этому не относиться.
