Design - Dependency Dell Qaroringiz?

BLL va DALdan tashkil topgan model bilan MVC arxitekturasidan foydalanamiz.

Shunday qilib, biz tizimimiz uchun "modullar" ni ishlab chiqamiz va men amalga oshiradigan muayyan narsa bir xil bog'liqliklardan foydalanishadi. Ayniqsa, bitta sinfda 20 ta bog'liqlik mavjud. Ayni paytda standart konstruktor sukut bo'yicha aniq konstruktsiyani ishlab chiqadi va bizda ham o'zga bog'liqliklarni (ya'ni sinovdan o'tkazishni) imkon beradigan ikkinchi konstruktor mavjud.

20 konstruktiv argumentlar juda yomon kod hidiga o'xshaydi. Boshqa bezovta qiluvchi narsa ko'pincha umumiy funktsionallikni qo'shishga boshlaganimda, men har bir sinfda konstruktiv kodi va maydonlarini qo'shishni davom ettirishim kerak, ko'pincha bir xil turdagi kodlarni qayta-qayta takrorlash.

IoC konteyner bu tabiiy yechim kabi ko'rinadi, ammo muammo qanchalik uzoqqa boradi? DAL bog'liqliklar va BLL bog'liqliklarini o'zimga qo'shyapmanmi? "Yordamchi" yoki "xizmat" bog'liqliklar haqida nima deyish mumkin? Men ma'lum bir nuqtada, faqat "nom maydoni" tuzilishini statik sinflar singari mening kurslarga murojaat qilish qobiliyatini qayta yaratmoqdaman.

Men bu haqda o'ylayman. Har kimda oqlangan, bir yechim yoki maslahat bormi?

0
Tangentially bilan bog'liq: bu erda bir sinf olgan bog'liqliklar sonini kamaytirish haqida boshqa savol uchun yozgan javob. stackoverflow.com/questions/5601920/…
qo'shib qo'ydi muallif Domenic, manba
"Men bu haqda o'ylayman". Ushbu qo'llanmani ko'rib chiqing: github.com/ninject/ninject/wiki
qo'shib qo'ydi muallif Merlyn Morgan-Graham, manba

1 javoblar

IoC marshrutiga chiqsangiz (men tavsiya qilsam), men sizning barcha bog'liqliklaringizni konteynerga kiritaman.

Foydasi shundaki, unda bir tonna chuqurlik mavjud bo'lsa-da, ushbu bog'liqliklarni yaratishda xavotir olmang.

Masalan, ClassA o'z konstruktorida 4 ta boshqa sinfni oladi, ularning har biri o'zlarida ikkita boshqasini oladi va ularning har biri kamida bitta DAL mos yozuvi oladi.

Bunday holatda siz o'zingizning interfeysingiz bo'lishi mumkin bo'lgan "yuqori darajadagi" qatlamingizda ("kompozitsion ildiz") IoC ga murojaat qilishingiz va "ob'ekt A ob'ektining namunasini berishingiz" ni ayting. IoC ob'ekt grafikasini yaratish uchun zarur bo'lgan turli xil bog'liqliklar uchun boshqa 20 ta misolni avtomatik tarzda belgilaydi.

Sizning sinflaringiz, agar ular faqat konstruktorga yopishgan narsaga muhtoj bo'lsa va ular IoC ga ega bo'lishini ta'minlasalar, o'zlarining bog'liqliklarini qanday qilib yaratishni o'ylashlari kerak emas.

Bundan tashqari, IoC dan foydalanayotgan bo'lsangiz ham, bitta sinfdagi 20 ta bog'liqlik aniq kodli hidi. Odatda, sinf juda ko'p narsalarni qiladi va Yagona javobgarlik printsipi ni buzadi.

7
qo'shib qo'ydi
+1 - IoC ning ("MVC" punktini istisno qilish) va "automagically" atamasidan foydalanganingiz uchun aniq yo'nalish ekanligiga qat'iy qo'shilaman.
qo'shib qo'ydi muallif Reddog, manba
SRP buzilishi haqida eslatma uchun +1. Dizaynga qarashning mutlaqo yaxshi fikri.
qo'shib qo'ydi muallif Joshua Rodgers, manba