Spring AOP

Aspekt-oriented dasturlash (AOP) objekt-oriented dasturlashni (OOP) to'ldiradi, dastur tuzilmasini o'zgacha usulda tushunishni ta'minlaydi. OOP-da modulning asosiy birligi klass bo'lsa, AOP’da modulning asosiy birligi aspekt hisoblanadi. Aspektlar ko’plab turlar va obyektlarni qamrab oluvchi funksionallikni (masalan, tranzaksiyalarni boshqarishni) modulga oid tashkil qiladi. (AOP bo'yicha adabiyotda bunday funksionallik "kesma (crosscutting)" deb yuritiladi.)

Springning asosiy komponentlaridan biri AOP-freymvorkdir. Garchi Spring IoC konteyneri AOP-ga bog'liq bo'lmasa (ya'ni siz istamasangiz AOP dan foydalanishingiz shart emas), AOP Spring IoC-ni to’ldiradi va bu oraliq dastur uchun juda mos yechimni ta’minlaydi.

AOP Spring Framework-da foydalaniladi:

• Deklarativ korporativ xizmatlarni taqdim etishda. Eng muhim xizmatlardan biri bu deklarativ tranzaksiya boshqaruvi.

• Foydalanuvchilarga OOPdan foydalanishni AOP bilan to'ldirib, maxsus aspektlarni amalga oshirishga imkon berish.

AOP tushunchalari

Keling, AOPning ba'zi asosiy tushunchalari va terminologiyasini aniqlashdan boshlaylik. Ushbu atamalar Springga xos emas. Afsuski, AOP terminologiyasi juda tushunarli emas. Ammo, agar Spring o'z terminologiyasini qo'llasa, bu yanada chalkashroq bo'ladi.

• Aspekt (aspect): Bir necha klasslarni qamrab oluvchi modullashtirilgan funksionallik (concern). Tranzaksiyalarni boshqarish Java korporativ ilovalarida kesma funksionallikning yaxshi misoli hisoblanadi. Spring AOPda aspektlar oddiy klasslar (sxema asosidagi yondashuv) yoki @Aspect annotatsiyasi bilan belgilangan oddiy klasslar (@AspectJ stili) yordamida amalga oshiriladi.

• Biriktirish nuqtasi (joint point): Dasturiy ta’minotning bajarilish vaqtidagi nuqtasi, masalan, metodning bajarilishi yoki istisno bilan ishlov berilishi. Spring AOPda biriktirish nuqtasi doim metodning bajarilishi hisoblanadi.

• Advice: Ma’lum bir biriktirish nuqtasida aspekt tomonidan amalga oshirilgan harakat. Har xil turdagi Advice-lar "atrofida (around)", "oldin (before)" va "so'ng (after)" maslahatlardan iborat. (Advice turlari keyinroq ko'rib chiqiladi). Ko'pgina AOP-freymvorklar, shu jumladan Spring, Советlarni interceptor sifatida modellashtiradi va biriktirish nuqtasi o'rniga interceptorlar zanjirini qo'llab-quvvatlaydi.

• Kesma (pointcut): Biriktirish nuqtalariga mos keladigan predikat. Advice kesma ifodasi bilan bog'langan va kesma bilan mos keladigan har qanday biriktirish nuqtasida bajariladi (masalan, ma’lum bir ismga ega metodni bajarish). Biriktirish nuqtalarini kesmalar bilan moslashtirish tushunchasi AOPda muhim ahamiyatga ega, Spring odatda kesmalar ifodasi AspectJ tilidan foydalanadi.

• Kirish (introduction): Tip nomidan qo'shimcha metodlar yoki maydonlarni e'lon qilish. Spring AOP yangi interfeyslarni (va mos keluvchi implementatsiyani) Advice bilan ta’minlangan har qanday obyektga joriy etishga imkon beradi. Misol uchun, keshlashni osonlashtirish uchun binni IsModified interfeysini majburiy ravishda amalga oshirish uchun kirishni ishlatishingiz mumkin. (AspectJ jamoasida kirish intertype declaration deb nomlanadi).

• Maqsad obyekti (Target object): Bitta yoki bir nechta aspektlar bo'yicha Advice bilan ta’minlanadigan ob'yekt. Shuningdek, "Advice bilan ta’minlangan obyekt" deb ham nomlanadi. Spring AOP dinamik proxy yordamida amalga oshirilgani sababli, bu obyekt doimo proxied obyekt bo'ladi.

• АОП прокси: Aspekt shartnomalarini amalga oshirish uchun AOP-freymvork tomonidan yaratilgan obyekt (metodlarni bajarishga Advice bilan ta’minlaydi va hokazo). Spring Frameworkda AOP-прокси – bu dinamik JDK proxy yoki CGLIB proxy.

• Боглаш (weaving): Aspektlarni boshqa ilova turlari yoki obyektlar bilan to’ldirilgan ob’yektni yaratish uchun bog'lash. Bu kompilyatsiya vaqtida (masalan, AspectJ компилятори yordamida), yuklash vaqtida yoki dastur bajarilishi vaqtida amalga oshirilishi mumkin. Spring AOP, boshqa sof Java AOP-freymvorklari singari, dastur bajarilishi vaqtida bog'lashni amalga oshiradi.

Spring AOP quyidagi turdagi maslahatlarga ega:

• "Oldin (before)" maslahati: Biriktirish nuqtasidan oldin bajariladigan, ammo biriktirish nuqtasiga ketayotgan bajarilish oqimini to'sib qo'yish imkoniyatiga ega bo'lmagan maslahati (faqatgina taklif bo'lmasa, u istisnolarni keltirib chiqarmasa).

• "Qaytarganidan keyin (after returning)" maslahati: Biriktirish nuqtasining normal yakunlanganidan keyin bajariladigan maslahati (masalan, agar metod istisno yaratmasdan qaytsa).

• "Istisno yaratganidan keyin (throwing)" maslahati: Agar metod istisno yaratib tugagan holda qaytsa, bajariladigan maslahati.

• "So'ng (finally)" maslahati: Biriktirish nuqtasidan chiqish usuliga (oddiy yoki istisno qaytarish) qarab bajarilishi kerak bo'lgan maslahati.

• "Atrofida (around)" maslahati: Biriktirish nuqtasini, masalan, metodni chaqirishni qamrab olgan maslahati. Bu maslahatlardan eng ta'sirli turi hisoblanadi. "Atrofida" maslahati metodni chaqirishdan oldin va metod chaqirilgandan keyin maxsus ishchi mantiqni qo'llash mumkin. U, shuningdek, biriktirish nuqtasiga o'tish yoki o'zining natija qiymatini qaytarib berish yoki istisno keltirib chiqaryotgan tavsiya qilingan metodni bajarishni qisqartirishni tanlaydi.

"Atrofida" maslahati - bu maslahatlardan eng umumiy turi. Spring AOP va AspectJ, maslahatlardan to'liq to'plamini taqdim etadi, shuning uchun biz tavsiya etilgan ishchi mantiqni amalga oshirish uchun eng kam ta’sir etuvchi maslahatlardan foydalanishni tavsiya etamiz. Masalan, agar sizga faqat metodning qaytarilgan qiymatini keshlashni yangilash kerak bo'lsa, "qaytarganidan keyin" maslahati amalga oshirish yaxshiroq, garchi "atrofida" maslahati ham xuddi shunday ishni amalga oshirishi mumkin. Eng aniq maslahat turidan foydalanish kamroq xato ehtimoli bilan soddaroq dasturlash modelini ta’minlaydi. Masalan, "atrofida" maslahati uchun "JoinPoint" uchun proceed() metodini chaqirish shart emas, shu sababli uni chaqirishni unutib qo'yish mumkin emas.

Barcha maslahat parametrlarining tipi statik bo'lganligi sababli, siz maslahat parametrlarining mos keluvchi tipi bilan (masalan, metod bajarilganida qaytish qiymati tipi) emas, Object massivlari bilan ishlaysiz.

Biriktirish nuqtalarini kesmalar bilan moslashtirish tushunchasi AOPni tushunishning kaliti bo'lib, bu uni faqat interception taklif qiluvchi eski texnologiyalardan ajratib turadi. Kesma maslahatlarga object-oriented iyerarxiya bo'yicha mustaqil murojaat qilish imkonini beradi. Masalan, deklarativ tranzaksiya boshqaruvini ta'minlaydigan "atrofida" maslahatni bir nechta ob’yektlarni (masalan, barcha biznes operatsiyalarni xizmat darajasida) qamrab oluvchi metodlar to'plamiga qo'llash mumkin.

Spring AOP imkoniyatlari va maqsadlari

Spring AOP sof Javada amalga oshirilgan. Maxsus kompilyatsiya jarayoniga ehtiyoj yo'q. Spring AOP klassyükleyici iyerarxiyasini boshqarishni talab qilmaydi va shuning uchun servier konteynerida yoki ilova serverida ishlatish uchun javob beradi.

Spring AOP hozirda faqat metodlarni bajarish biriktirish nuqtalarini qo'llab-quvvatlaydi (Spring binlari uchun maslahatlardan foydalanish). Maydon interception amalga oshirilmagan, garchi maydon interception qo'llab-quvvatlashi asosiy Spring AOP API-larni buzmasdan ham qo'shilishi mumkin. Agar sizga maydonga kirishni va nuqtalarini yangilashni maslahatlardan foydalanish kerak bo'lsa, AspectJ singari tilni ko'rib chiqing.

Spring AOPning AOPga yondashuvi ko'pgina boshqa AOP-freymvorklarda farqli o'laroq. Maqsad AOPning eng to'liq amalga oshirilishini taqdim etish emas (garchi Spring AOP buni qila olsa ham). Aksincha, maqsad AOP amalga oshirilishi va Spring IoC-ni yaqin integratsiyalashdir, bu korporativ ilovalardagi umumiy tizim muammolarini hal qilishga yordam beradi.

Misol uchun, Spring Frameworkdagi AOP funksionalligi odatda Spring IoC konteyneri bilan birgalikda ishlatiladi. Aspektlar oddiy binlar ta'riflash sintaksisi orqali konfiguratsiyalanadi (garchi bu yuqori samaradorlikdagi "auto-proxying" imkoniyatlaridan foydalanishga imkon beradi). Bu boshqa AOP amalga oshirilishlaridan ajralib turadi. Siz Spring AOP orqali ba’zi narsalarni osonlik va samarali amalga oshira olmaysiz, masalan, juda mayda o'lchamli obyektlarni maslahatlardan foydalanish (odatda, domen obyektlari). AspectJ bunday holatlarda eng yaxshi tanlovdir. Biroq, bizning tajribamiz shuni ko'rsatadiki, Spring AOP AOPga bo'ysunuvchi korporativ Java ilovalaridagi ko'pgina muammolar uchun a'lo darajada yechim taqdim etadi.

Spring AOP hech qanday holatda AOPning to'liq yechimlarini taqdim etuvchi AspectJ bilan raqobatlashishni maqsad qilmagan. Bizning fikrimizcha, Spring AOP singari proxy-orient freymvorklar va AspectJ singari to'liq freymvorklar qimmatli bo'lib, bir-birini to'ldiruvchi, raqobatchi emas. Spring AOP va IoC AspectJ bilan osongina integratsiyalashadi, bu Spring bazasidagi ilovalarning uyg'un arxitekturasida AOPdan foydalanish imkoniyatini beradi. Ushbu integratsiya Spring AOP API yoki AOP Alliance APIlariga ta'sir qilmaydi. Spring AOP hali ham orqaga mos keladi.

АОП прокси

Spring AOP odatda стандарт JDK dinamik proxylardan AOP-proxi uchun foydalanadi. Bu har qanday interfeys (yoki interfeyslar to'plami)ni proxylash imkonini beradi.

Spring AOP CGLIB proxylardan ham foydalanishi mumkin. U interfeyslarni emas, balki klasslarni proxylash uchun zarur. Oddiy holda, CGLIB biznes obyekt interfeysni amalga oshirmasa, foydalaniladi. Interfeyslarga dasturlash tavsiya etilgani uchun, biznes klasslar odatda bitta yoki bir necha biznes interfeyslarini amalga oshiradi. CGLIBdan foydalanishni aniq qilib aytish (umid qilamiz, kamdan-kam hollarda), agar interfeysda e'lon qilinmagan metodni maslahatlardan foydalanish zarur bo'lsa yoki metodga proxied obyektni aniq tur sifatida o'tkazish kerak bo'lsa, kerak bo'lishi mumkin.

Spring AOP proxylarga asoslanganligini tushunish muhimdir.