Design - Dependency Hell Solution?

Біз MVC архитектурасын BLL және DAL тұратын модельмен қолданамыз.

Сондықтан біздің жүйеміз үшін «модульдерді» әзірлейміз, ал мен іске асыратын нақты бір тәуелділіктердің көптігін пайдаланады. Бір сыныпта, атап айтқанда, 20 тәуелділік бар. Қазіргі уақытта әдетті конструктор әдепкі нақты орындауды жасайды, және бізде де өз тәуелділіктерді (мысалы, тестілеу) инъекциялауға мүмкіндік беретін екінші конструктор [бірінші пайдаланатыны] бар.

20 конструктор аргументтері өте жаман код иісіне ұқсайды. Басқа да тітіркендіргіш нәрсе жиі-жиі ортақ функционалдылықты қосуды бастағанда, әр сыныптағы конструктор кодын және өрістерді қосып, қайтадан бірдей код түрін қайта-қайта қайталау керек.

IoC контейнері бұл үшін табиғи шешім ретінде көрінеді, бірақ мәселе қаншалықты алысқа барады? DAL тәуелділіктерін және BLL тәуелділіктерін қосу керек пе? Ал «көмекші» немесе «қызмет» тәуелділігі туралы не деуге болады? Менің ойымша, белгілі бір сәтте мен «есім кеңістігі» құрылымын статикалық класстар сияқты сабақтарға сілтеме жасау мүмкіндігімен қайта жасаймын.

Мен бұл туралы ойлану қиын. Кез келген талғампаз шешім немесе кеңес бар ма?

0
Тангендігімен байланысты: мұнда сыныптың тәуелділіктерінің санын қысқарту туралы басқа сұраққа жауап жаздым. stackoverflow.com/questions/5601920/…
қосылды автор Domenic, көзі
«Мен осы арқылы ойлауға қиындық туды». Осы оқулықты қарап шығыңыз: github.com/ninject/ninject/wiki
қосылды автор Merlyn Morgan-Graham, көзі

1 жауаптар

Егер сіз IoC маршрутына барсаңыз (мен ұсынамын), сіздің барлық тәуелділіктеріңізді контейнерге қосасыз.

Пайдасы, сіз бұл тәуелділіктерді құру туралы ешқашан алаңдамауыңыз керек, тіпті олардың бір тоннасы терең болса.

мысалы, ClassA конструктордағы 4 басқа сыныпты алады, олардың әрқайсысы өздерінің екеуінде қабылдайды және олардың әрқайсысы кем дегенде DAL сілтемесін алады.

Бұл жағдайда сіз өзіңіздің UI болуы мүмкін жоғары деңгейлі қабаттағы («композициялық түбір») IoC сілтемесіне жүгініңіз және «А нысанын данасын беріңіз» деп айтыңыз, содан кейін IoC нысан диаграммасын құру үшін қажетті әртүрлі тәуелділіктер үшін басқа 20 дананы автоматтандырады.

Сіздің сыныптарыңыз өздерінің тәуелділіктерін қалай құруға болатынын алаңдатудың қажеті жоқ, егер олар оны конструкторда ұстайтын нәрсеге мұқтаж болса және IoC оны алуға мүмкіндік береді.

Сондай-ақ, егер сіз IoC қолданып жатсаңыз да, бір сыныптағы 20 тәуелділіктің нақты код иісі болып табылады. Әдетте, бұл сынып өте көп нәрселерді жасап, Бірыңғай жауапкершілік қағидатына кедергі келтіретінін көрсетеді.

7
қосылды
+1 - IoC - бұл айқын маршрут (MVC-ны жазалауды ақтау), сондай-ақ «автоматтық түрде» терминін қолданғаныңыз туралы толық келіседі.
қосылды автор Reddog, көзі
+1 БТЖ бұзу туралы еске салу үшін. Дизайнды қараудың жақсы идеясы.
қосылды автор Joshua Rodgers, көзі