MVC arxitekturasi bilan tanishish
Har bir dasturchi bilishi kerak bo‘lgan eng mashhur ilova arxitekturasi — bu MVC. MVC Model-View-Controller deb nomlanadi.
Bu ilovalarning arxitekturasi emas, balki ilovalar komponentlari arxitekturasi, lekin bu nuqtaga keyinroq qaytamiz. Xo‘sh, MVC nima?
MVC — bu ilovaning ma'lumotlari va boshqaruv mantiqini uchta alohida komponentlarga ajratish sxemasi: model, ko‘rinish va boshqaruvchi. Shunday qilib, har bir komponentni o‘zgartirish mustaqil ravishda amalga oshirilishi mumkin.
- Model (Model) ma'lumotlarni taqdim etadi va boshqaruvchining buyruqlariga javob beradi, o‘z holatini o‘zgartiradi.
- Ko‘rinish (View) foydalanuvchiga modelning ma'lumotlarini ko‘rsatadi, model o‘zgarishiga javob beradi.
- Boshqaruvchi (Controller) foydalanuvchi harakatlarini interpretatsiya qiladi va modelga o‘zgarishlarning zaruriyligi haqida xabar beradi.
Bu model 1978 (!) yilda ixtiro qilingan. Ha, 50 yil oldin ham to‘g‘ri dasturiy ta'minot arxitekturasi bilan bog‘liq muammolar mavjud edi. Bu modelning asl diagrammada tavsifi:
Model ma'lumotlar va ularga ishlov berish usullarini taqdim etadi: ma'lumotlar bazasiga so‘rovlar, to‘g‘rilik tekshiruvlari. Model ko‘rinishga bog‘liq emas (ma'lumotlarni qanday vizualizatsiya qilishni bilmaydi) va boshqaruvchiga (foydalanuvchi bilan o‘zaro aloqasi yo‘q), ma'lumotlarga kirish va ularni boshqarishni ta'minlaydi.
Model shu tarzda quriladi, shunday qilib, o‘z holatini o‘zgartirib, so‘rovlarga javob beradi, bunda “kuzatuvchilarni” xabardor qilish kiritilgan bo‘lishi mumkin. Model, vizual ko‘rinishga mustaqilligi tufayli, bir “model” uchun bir nechta turli ko‘rinishlarga ega bo‘lishi mumkin.
Ko‘rinish modeldan zarur ma'lumotlarni olish va ularni foydalanuvchiga yetkazish uchun javobgardir. Ko‘rinish foydalanuvchi tomonidan kiritilgan ma'lumotlarni ishlov bermaydi.
Boshqaruvchi foydalanuvchi va tizim o‘rtasidagi “aloqani” ta'minlaydi. Foydalanuvchidan tizimga va aksincha ma'lumotlarni yo‘naltiradi va boshqaradi. Kerakli harakatlarni amalga oshirish uchun model va ko‘rinishni ishlatadi.
Bu model o‘nlab yillar davomida bir oz rivojlandi. Ya'ni, nomi o‘sha-o‘sha, lekin qismlarining vazifalari o‘zgarib ketdi.
Vebda MVC arxitekturasi
MVC dizayn shablonining asosidagi g‘oya juda oddiy: bizning ilovalarimizda turli xil funktsionallik uchun javobgarlikni aniq ajratish kerak:
Model — ma'lumotlar va ilova mantiqini ishga tushirish.
View — foydalanuvchiga ma'lumotlarni har qanday qo‘llab-quvvatlangan formatda taqdim etish.
Controller — foydalanuvchi so‘rovlari va tegishli resurslarni chaqirish bilan ishlash.
Ilova uchta asosiy komponentga bo‘linadi, har biri turli vazifalar uchun javobgardir. Keling, mijoz-server ilovasining komponentlarini misol bilan batafsil tahlil qilaylik.
Boshqaruvchi (Controller)
Foydalanuvchi brauzerdagi turli elementlarga bosadi, shunda brauzer turli HTTP so‘rovlarini yuboradi: GET, POST yoki boshqa. Boshqaruvchiga brauzer va sahifa ichida ishlaydigan JS-kodni kiritish mumkin.
Bunda boshqaruvchining asosiy vazifasi kerakli ob'ektlarga bosishlar chaqirish, foydalanuvchiga qo‘yilgan vazifalarini bajarish uchun resurslarga kirishni boshqarishdir. Odatda, boshqaruvchi vazifani bajarish uchun mos modelni chaqiradi va mos ko‘rinishni tanlaydi.
Model (Model)
Model keng ma’noda — bu ma'lumotlar va ma'lumotlar bilan ishlash uchun ishlatiladigan qoidalar — ular birgalikda ilovaning biznes mantiqini tashkil qiladi. Ilovani loyihalash har doim uning ishlatadigan obyektlar modelini yaratishdan boshlanadi.
Misol uchun, agar bizda kitoblar sotadigan internet-do‘kon bo‘lsa, unda inson — bu ilovaning foydalanuvchisi yoki kitobning muallifi hammi? Bu muhim savollar modelni loyihalashda hal qilinishi kerak.
Keyin qoidalar to‘plamlari keladi: nima qilish mumkin, nima mumkin emas, qanday ma'lumotlar to‘plamlari ruxsat etilgan va qandaylari yo‘q. Kitob muallifsiz bo‘lishi mumkinmi? Muallif kitoblarsiz bo‘lishi mumkinmi? Foydalanuvchining tug‘ilgan vaqti 300-yilda bo‘lishi mumkinmi va shunga o‘xshash savollar.
Model foydalanuvchi so‘ragan ma'lumotlarni boshqaruvchiga taqdim etadi (xabar, kitob sahifasi, surat va hokazo). Modelning ma'lumotlari foydalanuvchiga qanday ko‘rsatishimizdan qat'i nazar bir xil bo‘ladi. Shu sababli, biz ma'lumotlarni ko‘rsatish uchun istalgan mavjud ko‘rinishni tanlaymiz.
Model bizning ilovamizning eng muhim qismi — mantiqni o‘z ichiga oladi, biz duch kelgan vazifani hal qiladi (forum, do‘kon, bank va hokazo). Boshqaruvchi asosan ilovaning o‘ziga xos mantiqni saqlaydi (xuddi Project Manager’ga o‘xshab).
Ko‘rinish (View)
View modeldan olingan ma'lumotlarni turli usullar bilan taqdim etadi. U ma'lumotlar bilan to'ldirilgan shablon bo'lishi mumkin. Bir nechta turli views bo‘lishi mumkin va boshqaruvchi joriy vaziyat uchun eng mos keladiganini tanlaydi.
Veb-ilova odatda boshqaruvchilar, modelllar va views (ko‘rinishlar) to‘plamidan iborat. Boshqaruvchi faqat backendda bo‘lishi mumkin, lekin ba'zi hollarda bir nechta boshqaruvchilar bo‘lishi mumkin, bunda uning mantiqi frontendga ham tarqalishi mumkin. Bunday yondashuvning yaxshi misoli — har qanday mobil ilova.
Vebda MVC misoli
Farz qil, sen kitoblar sotadigan internet-do‘konni ishlab chiqishing kerak. Foydalanuvchi quyidagi harakatlarni bajarishi mumkin: kitoblarni ko‘rish, ro‘yxatdan o‘tish, sotib olish, joriy buyurtmaga elementlar qoʻshish, yoqtirilgan kitoblarni belgilash va sotib olish.
Sening ilovangda model bo‘lishi kerak, u butun biznes mantiqi uchun javobgar. Shuningdek, foydalanuvchi harakatlarini qayta ishlaydigan va ularni biznes-mantiqidan usullarni chaqirishga o‘tkazadigan boshqaruvchi kerak. Shu bilan birga, boshqaruvchining bir usuli modelning turli usullarini chaqirishi mumkin.
Shuningdek, sening bir qator views kerak: kitoblar ro‘yxati, bitta kitob haqida ma'lumot, savat, buyurtmalar ro‘yxati. Har bir veb-ilovaning sahifasi — bu aslida foydalanuvchiga modelning ma'lum bir aspektini ko‘rsatuvchi alohida viewdir.
Keling, foydalanuvchi kitob do'koni tomonidan tavsiya etilgan kitoblar ro'yxatini ochayotganida nima bo‘lishini ko‘raylik. Harakatlar ketma-ketligini 6 qadamda ta'riflash mumkin:
Qadamlar:
- Foydalanuvchi 'tavsiya etilganlar' havolasiga bosadi va brauzer so‘rov yuboradi, masalan /books/recommendations.
- Boshqaruvchi so‘rovni tekshiradi: foydalanuvchi login qilgan bo‘lishi kerak yoki bizda login qilmagan foydalanuvchilar uchun kitoblar to‘plamlari bo‘lishi kerak. Keyin boshqaruvchi modelga murojaat qiladi va foydalanuvchi N uchun tavsiya etilgan kitoblar ro‘yxatini so‘raydi.
- Model ma'lumotlar bazasiga murojaat qiladi, kitoblar haqida ma'lumotni oladi: hozir mashhur kitoblar, foydalanuvchi tomonidan sotib olingan kitoblar, do‘stlari sotib olgan kitoblar, wish listdan kitoblar. Ushbu ma'lumotlar asosida model 10 ta tavsiya etilgan kitoblar ro‘yxatini tuzadi va ularni boshqaruvchiga qaytaradi.
- Boshqaruvchi tavsiya etilgan kitoblar ro‘yxatini oladi va unga qaraydi. Bu bosqichda boshqaruvchi qaror qabul qiladi! Agar kitoblar kam yoki ro‘yxat umuman bo‘sh bo‘lsa, u login qilmagan foydalanuvchilar uchun kitoblar ro‘yxatini so‘raydi. Agar hozirda aksiyalar o‘tkazilayotgan bo‘lsa, boshqaruvchi ro‘yxatga aksiya kitoblarni qo‘shishi mumkin.
- Boshqaruvchi foydalanuvchiga qaysi sahifani ko‘rsatishni hal qiladi. Bu xato sahifasi, kitoblar ro‘yxati yoki foydalanuvchi millioninchi tashrifchi bo‘lganligi munosabati bilan tabrik sahifasi bo‘lishi mumkin.
- Server klientga boshqaruvchi tomonidan tanlangan sahifani (view) beradi. U kerakli ma'lumotlar (foydalanuvchi ismi, kitoblar ro‘yxati) bilan to‘ldiriladi va klientga yuboriladi.
- Klient sahifani oladi va uni foydalanuvchiga ko‘rsatadi.
Bunday yondashuvning qanday afzalliklari bor?
Biz MVC kontseptsiyasidan foydalanish orqali oladigan eng aniq afzallik loyihalash mantiqini (foydalanuvchi interfeysi) va ilova mantiqini (server qismi) aniq ajratishdir.
Ikkinchi afzallik server qismini ikkitaga ajratishdir: aqlli model (ijrochi) va boshqaruvchi (qaror qabul qilish markazi).
Oldingi misolda model tavsiya etilgan kitoblar ro‘yxati bo‘sh bo‘lishi mumkin va qanchalik ko‘p variant bo‘lishi mumkinligini ko‘rsatadiki, boshqaruvchi bu ro‘yxat bilan nima qilish kerakligini hal qiladi. Nazariy jihatdan bu mantiqni darhol modelga joylashtirish mumkin edi.
Tavsiya etilgan kitoblar so‘rovi paytida model, agar ro‘yxat bo‘sh bo‘lsa, nima qilish kerakligini hal qilgan bo‘lar edi. Keyin ushbu joyga kod qo‘shilishi kerak bo‘lar edi, agar hozirda aksiyalar o‘tkazilayotgan bo‘lsa, keyin yana turli variantlar qo‘shilishi kerak bo‘lar edi.
Keyin ma'lum bo‘ldiki, do'kon admini kampaniyasiz foydalanuvchi sahifasini qanday ko‘rinishini ko‘rib chiqmoqchi bo‘ldi yoki hozirda kampaniya yo‘q, lekin u kelajakdagi kampaniyasiz qanday ko‘rinishini ko‘rib chiqmoqchi edi. Va buning uchun usullari yo‘q. Shuning uchun qaror qabul qilish markazini (boshqaruvchi) biznes-mantiqdan (model) ajratishga qaror qilindi.
Kirish vaqti va ilova mantiqligidan yuklarni ajratib olishdan tashqari, MVC kontseptsiyasi katta ilovalarning murakkabligini sezilarli darajada kamaytiradi. Kod ancha tuzilgan bo‘ladi va bu tushunish, sinov va qayta ishlatishni osonlashtiradi.
MVC kontseptsiyasini tushunib, dasturchi sifatida kitoblar ro‘yxatini saralash kerak bo‘lgan joyni bilasiz:
- Ma'lumotlar bazasi so‘rov darajasida.
- Biznes-mantiq darajasida (model).
- Biznes-mantiq darajasida (boshqaruvchi).
- Ko‘rinishda — mijoz tomonda.
Bu ritorik savol emas. Endi o‘ylab ko‘r: kitoblar ro‘yxatini saralash uchun kodni qayerda va nima uchun qo‘shish kerak.
An'anaviy MVC modeli
MVC komponentlarining o‘zaro ta'siri veb-ilovalarda va mobil ilovalarda turlicha amalga oshiriladi. Veb-ilova — qisqa yashaydi, bitta foydalanuvchi so‘rovini qayta ishlaydi va tugatadi, mobil ilova esa bir nechta so‘rovlarni qayta ishlaydi, lekin qayta ishga tushiriladi.
Veb-ilovalarda odatda "passiv" model, mobil ilovalarda esa "faol" model ishlatiladi. Faol model, passiv modeldan farqli o‘laroq, undagi o‘zgarishlar haqida xabarnoma olishni ta'minlaydi. Veb-ilovalarda bunga ehtiyoj yo‘q.
Turli modellar bo‘yicha komponentlarning o‘zaro ta'siri taxminan quyidagicha ko‘rinadi:
Mobil ilovalarda (faol model) voqealar va voqealarga abonelik mexanizmi keng qo‘llaniladi. Ushbu yondashuvda view (ko‘rinish) modeldagi o‘zgarishlarga obuna bo‘ladi. Keyin, biror voqea sodir bo‘lganda (masalan, foydalanuvchi tugmani bossa), boshqaruvchi chaqiriladi. U modelga ma'lumotlarni o‘zgartirish uchun buyruq beradi.
Agar ba'zi ma'lumotlar o‘zgarsa, model o‘sha ma'lumotlarning o‘zgarishi haqida voqea yaratadi. Bu voqeaga obuna bo‘lgan barcha ko‘rinishlar (ayniqsa ushbu ma'lumotlarning o‘zgarishi muhim bo‘lsa) bu voqeani qabul qiladi va o‘z interfeysida ma'lumotlarni yangilaydi.
Veb-ilovalarda barchasi biroz boshqacha tashkil etilgan. Asosiy texnik farq — bu klient server tashabbusi bilan server tomonidan xabarlar qabul qila olmaydi.
Shuning uchun veb-ilovadagi boshqaruvchi odatda viewga biror xabar yubormaydi, balki klientga yangi sahifa beradi, bu texnik jihatdan yangi view yoki hatto yangi klient ilovasi bo‘ladi (agar bir sahifa boshqasini bilmasa).
Hozirgi kunda bu muammo qisman quyidagi yondashuvlar yordamida hal qilinmoqda:
- Ahamiyatli ma'lumotlarning o‘zgarishini tekshirish uchun serverni muntazam tekshirish (har daqiqada yoki tez-tez).
- WebSocket’lar klientga server xabarlariga obuna bo‘lishga imkon beradi.
- Serverdan web-push xabarnomalar.
- HTTP/2 protokoli serverga klientga xabar yuborishni tashabbus qilish imkonini beradi.
GO TO FULL VERSION