MVC, MVP va MVVM

• Arxitektura nima?
• Arxitekturaning o’rni
• Android-da yaxshi arxitekturaga erishish uchun kerak bo’ladigan ba’zi tamoyillar
• Arxitektura patternlari
• MVC
• MVP
• MVVM

Arxitektura o’zi nima?

Agar biz dasturni bir nechta qoidalarga asoslanib qurayotgan bo’lsak, tegishli funksiyalarni ishlatib va ma’lum bir protokollar bilan ularni ishga tushirsak buni biz “Arxitektura” deb nomlashimiz mumkin.

Arxitekturaning o’rni

Aytaylik, agar biz biror bir arxitekturadan foydalanmasak va o’z kodimizni class, activity, yoki fragmentda tartibsiz ravishda yozsak, u holda biz quyidagi muammolar duch kelishimiz mumkin:

• Tushunish qiyin bo’lgan kodlarning qatorlari ko’payib borishi
• Kodni o’qishni yanayam qiyinlashtiribgina qolmay, bug larni sonini ham bir munchaga oshirib yuborish. Shuning uchun ham bunda dasturni test qilish oson bo’lmasligi va bu mahsulotni sifatini tushirishga olib keladi

Demak aniq bir malumotlar oqimini ta’minlash, mustahkamlilik, o’lchovlilik, xatolarga chidamlilik, tushunarlilik, o’zgartirishlilikni oson va samaradorlikni oshirish bilan birga, sifatli dasturni ham taqdim etadi. Endi biz jamoada ishlash uchun mos bo’lgan arxitekturadan foydalanishimiz kerak ekanligini tushundik.

Android da yaxshi arxitekturaga erishish uchun kerak bo’ladigan ba’zi tamoyillar

Yaxshi arxitekturaga erishish uchun biz ba’zi bir asosiy tushunchalarga amal qilishimiz kerak. Ular:

• Seperation of concern: vazifalarni alohida bo’limlarga ajratib har bir bo’lim o’ziga tegishli masalani hal qilishi uchun foydalaniladi.

Va biz buni faqat Arxitektura Patternlari bilan bajara olamiz.

• No Hard dependency: Agar har bir tarkibiy qism belgilangan miqdordagi dependency lar bilan ishlashi kerak bo’lsa, uni tuzatish kerak. Barcha dependency lar tashqaridan ta’minlanishi kerak. Dependency Injection dan foydalaning.
• Lifecycle va ma’lumotlar uzviyligini boshqarish: Bu Arxitektura Componenti bilan amalga oshiriladi.

Arxitektura Patternlari

Dasturiy ta’minotning Arixitektura Dizayni Pattern ni uyushgan dasturlashni targ’ib qiladi. Test qilish oson bo’lgan va arzon narxlardagi texnik xizmat ko’rsatishni ta’minlaydigan dastur funksiyalarini ajratib turadi. MVC, MVP, MVVM — bular eng mashhur arxitektura patternlardan biri. Keling, ularni birma-bir o’rganib chiqamiz:

MVC

Bu Model — View — Controller. Eng ko’p ishlatiladigan arxitektura. Quyida MVCda ishlatiladigan uchta komponentalar bilan tanishib chiqamiz:

Model — Bu biznes logika va Data State(Ma’lumotlar holati). Ma’lumotlarni olish va boshqarish, Controller bilan aloqa o’rnatib, ma’lumotlar bazasi bilan muloqot qilib, ba’zida Viewni yangilaydi.

View — bizga ko’rinadigan narsalar. Foydalanuvchi interfeysi HTML / CSS / XML dan iborat. U Controller bilan aloqa qiladi va ba’zida model bilan muloqot qiladi. Controller orqali ba’zi dinamik ko’rinishlarni o’tkazadi.

Controller — Bunga Activity/Fragment kiradi. View va Model bilan aloqa qiladi. Controller view/REST xizmatlaridan foydalanuvchi ma’lumotlarni oladi. Get data so’rovini Modeldan olib, Viewga o’tkazadi.

Afzalliklari

• Biznes Logikani alohida Model da saqlaydi
• Asenkron texnikani qo’llab quvvatlaydi
• O’zgartirish butun modelga ta’sir qilmaydi
• Tezroq rivojlanadi

Kamchiliklari

• Kod hajmi kattalashgach Controllerni boshqarib bo’lmay qoladi
• Unit testingni qiyinlashtiradi
• Murakkablikni oshiradi

MVP

Bu Model — View — Presenter. Arxitekturalarni qatlamlarga bo’lish dasturni ishlab chiqish vaqti uchun juda muhimdir.

Model — Bu biznes logika va malumotlar holati. Ma’lumotlarni olish va boshqarish, Presenter bilan aloqa o’rnatadi, ma’lumotlar bazasi bilan muloqot qiladi. U View ga ta’sir qilmaydi.

View — UI, activity, fragmentdan tashkil topadi. Presenter bilan muloqot qiladi.

Presenter — Bu modeldagi ma’lumotlarni taqdim etadi. Dastur ko’rsatishi mumkin bo’lgan har qanday xatti-harakatni boshqaradi. Viewni nazorat qiladi. U View ga nima qilishlikni kerakligini aytadi. Model va View o’rtasidangi har qanday aloqa Presenter tomonidan boshqariladi.

Afzalliklari

• View and Presenter dan qayta foydalanish mumkin
• Kod saqlash uchun qulay va o’qish uchun tushunarli
• Biznes Logika UI dan alohida bo’lgani uchun test qilish oson

Kamchiliklari

• View va Presenter o’rtasida zich bog’lanish
• Layerlar o’rtasidagi o’zaro muloqot uchun juda ko’p interface
• Kod hajmi juda katta

MVVM

Bu Model — View — ViewModel. U har bir komponent orasidagi zich bog’lanishni yo’qotadi. Observables tushunchasida ishlaydi. Bola klasslarda ota klasslarga tegishli ma’lumot yo’q, ular faqat observables bo’yicha ma’lumotlarga ega.

Model — Bu biznes logika, lokal va masofaviy ma’lumot manbai va repository(ombor) ga ega. Repository: ViewModel so’roviga binoan mahalliy yoki masofaviy ma’lumotlar manbalari bilan aloqa qiladi.

View — Faqat foydalanuvchi bilan o’zaro munosabat, ya’ni XML, biznes logikasi yo’q. Modelni ko’rish uchun to’g’ridan-to’g’ri foydalanuvchi harakatlarini yuboring, lekin to’g’ridan-to’g’ri javob olmaydi. Javobni ko’rish uchun ViewModel ko’rsatadigan ba’zi ma’lumotlar kuzatiladi.

ViewModel — Foydalanuvchi interfeysining aksariyat logika qismi shu yerda joylashadi. Buni View va biznes logikasi o’rtasidagi ko’prik desa ham bo’ladi. ViewModel qaysi View dan foydalanish kerakligini bilmaydi chunki undan View ga tog’ridan to’g’ri aloqa yo’q. Shuningdek test qilish va bog’lash uchun yaxshi. Ammo, shunga qaramay, observables orqali UIni yangilash kerak. Ma’lumotlar o’zgarganda, observable xabar beradi.

Afzalliklari

• View va ViewModellar o’rtasida zich bog’liqlik yo’q
• View va model o’rtasida interface lar yo’q
• Unit test uchun oson

Kamchiliklari

• Har bir UI komponenti uchun observable yaratishingiz kerak
• Kod hajmi bir muncha katta

MVVM ga oid loyihani bu yerdan topishingiz mumkin.

Men sizga arxitektura pattern lari haqida aniq tasavvur berishga harakat qildim. Umid qilamanki, bu sizga yordam beradi.

Bilim ulashish yo’lida bu maqolani dasturlashga qiziquvchilar bilan bo’lishing.

Maqola quyidagi link asosida tarjima qilindi.