Autofac, IoC и разделяне на слоеве

В моя ASP.NET MVC 4 c# проект имам 3 слоя. Данни, бизнес и уеб. Следвам модел на хранилище и услуги.

Използвам Autofac за инжектиране на зависимости. Това, което направих, беше да регистрирам компоненти в global.asax. По този начин трябваше да реферирам моя слой данни, където внедрих хранилища.

Мисля, че това нарушава правилото, защото моят уеб проект има препратка към слой данни.

Прочетох няколко статии за решаването на този проблем и намерих модули Autofac. Въпреки това не можах да намеря метод за прилагането му, без да препращам и към слоя данни.

Има ли начин да регистрирате компонентите, без да препращате към слоя данни?

Благодаря ти.


dependency-injection c# asp.net-mvc autofac ioc-container
person SherleyDev    schedule 10.11.2013    source източник
comment
Къде са дефинирани интерфейсите, които слоят данни изпълнява?   -  person Keith Payne    schedule 10.11.2013
comment
Слоят на данните се състои от генерично хранилище и единица работни класове, както и класове хранилища, извлечени от генерично хранилище. Всъщност имам 4 проекта, 3 от тях са споменати във въпроса, а 4-тият е проект на домейн, където внедрявам обекти (първи код). Услугите са в бизнес слоя.   -  person SherleyDev    schedule 10.11.2013
comment
Свързани: stackoverflow.com/a/9503612/126014   -  person Mark Seemann    schedule 10.11.2013
comment
Благодаря ти Марк. Прочетох тази публикация и вашата основна статия за състава. Сега съм объркан относно използването на модулите Autofac. Ако е добре да регистрирам компонентите в рамките на моя презентационен слой (MVC приложение - global.asax) чрез добавяне на препратки към проекти, тогава защо трябва да използвам модули? Благодаря ти много.   -  person SherleyDev    schedule 10.11.2013
comment
@SherleyDev: не си разбрал правилно. Коренът на композицията не е във вашия презентационен слой. Коренът на композицията е различен слой (негов собствен слой), въпреки че можете физически да го поставите в същия сборник като презентационния слой.   -  person Steven    schedule 10.11.2013
comment
Защо са ви необходими модули? Това е добър въпрос. Бих казал, че едва ли ще имате нужда от такава функция.   -  person Steven    schedule 10.11.2013
comment
@Steven: И така, това, което трябва да направя, е да създам отделен библиотечен проект за root композиция, който препраща към всички необходими проекти (като домейн, бизнес и т.н.) и след това препраща към този проект в mvc приложение, нали?   -  person SherleyDev    schedule 10.11.2013
comment
@SherleyDev: Не! Абсолютно не. Слой != монтаж. Сглобката е артефакт за разполагане. Слоят е логически артефакт. Извличането на корена на композицията в собствената му сборка само ще направи нещата по-трудни и няма никакви предимства. Моля, прочетете и моя отговор на въпроса, който Марк посочи.   -  person Steven    schedule 10.11.2013
comment
@Steven: Напълно съм объркан. И така, за да следвам практиката, която споменахте, какво трябва да направя? Трябва ли да използвам файл за стартиране и да го извикам от global.asax? Имате ли статия/блог, представяща тази ситуация?   -  person SherleyDev    schedule 10.11.2013
comment
нека да продължим тази дискусия в чата   -  person Steven    schedule 10.11.2013

Отговори (1)


arrow_upward
1
arrow_downward

Според мен ситуацията, която имате, е точно това, което търсите.

Не искате референтна структура като тази: LibA => LibB => LibC => ...

В крайна сметка това, което искате, е един DLL/проект/компонент, който да свързва всичките ви проекти заедно (известен като корен на композицията) и да няма зависимости между вашите компоненти. По този начин вашият домейн слой не зависи от нищо друго.

Добре е да препращате към вашия слой данни от вашия презентационен слой (ако там е коренът на вашата композиция).

Модулите са полезни, ако искате различни корени на състава за различните части на вашето приложение. Хипотетичен пример би била административна зона и клиентска зона. В случай, че техните зависимости са достатъчно различни, може да искате да използвате композиционен корен за всяка област, въпреки че те живеят в един и същи проект.

person Kenneth    schedule 10.11.2013