Qanday qilib tegishli iOS Arxitekturasini tanlash mumkin (2 qism)

MVC, MVP, MVVM, VIPER yoki VIP

Siz bu erda birinchi qism bilan maslahatlashishingiz mumkin.

Asosiy iOS arxitekturalari

Qisqacha sharh.

MVC

MVC qatlamlari quyidagicha:

M: biznes mantig'i, tarmoq sathi va ma'lumotlarga kirish qatlami

V: UI qatlami (UIKit buyumlari, hikoyalar, xiblar)

C: Model va View o'rtasida vositachilikni muvofiqlashtiradi.

MVC-ni tushunish uchun biz u ixtiro qilingan kontekstni tushunishimiz kerak. MVC eski veb-ishlab chiqish kunlarida ixtiro qilingan, bu erda Views yo'q. Qadimgi vaqtlarda har safar veb-saytni vizual ravishda o'zgartirishimiz kerak bo'lsa, brauzer yana HTMLni qayta yuklaydi. O'sha paytda ko'rish holati saqlanib qolishi haqida tushuncha yo'q edi.

Masalan, bir xil HTML-fayl, PHP va ma'lumotlar bazasiga kirishni aralashtirgan ba'zi ishlab chiquvchilar bor edi. Shunday qilib, MVC ning asosiy g'ayrati View qatlamini Model qatlamidan ajratish edi. Bu Model qatlamining sinov qobiliyatini oshirdi. Aytaylik, MVC-da View va Model qatlamlari bir-birlari haqida hech narsa bilmasligi kerak. Buni amalga oshirish uchun Controller deb nomlangan vositachi qatlam ixtiro qilindi. Bu qo'llanilgan SRP edi.

MVC tsikliga misol:

  1. Ko'rish qatlamidagi foydalanuvchi harakati / hodisasi (masalan: Refresh Action) ishdan bo'shatilgan va u boshqaruvchi bilan bog'langan
  2. Model qatlamiga ma'lumotlarni so'raydigan boshqaruvchi
  3. Modelni ma'lumotlarni boshqaruvchiga qaytaradi
  4. Nazoratchi "View" holatini yangi ma'lumotlar bilan yangilashini aytdi
  5. Uning holatini yangilashni ko'rish

Apple MVC

IOS-da View Controller UIKit va hayot aylanishi ko'rinishi bilan birlashtirilgan, shuning uchun u toza MVC emas. Biroq, MVC ta'rifida, Controller View yoki Modelning aniq bajarilishini bilmasligi haqida hech narsa aytilmaydi. Uning asosiy maqsadi Model qatlamini View qatlamidan ajratish, shuning uchun biz uni qayta ishlatib, izolyatsiya qilingan holda Model qatlamini sinab ko'rishimiz mumkin.

ViewController View-ni o'z ichiga oladi va Modelga egalik qiladi. Muammo biz ViewController-da nazorat kodini, shuningdek ko'rish kodini yozish uchun ishlatiladi.

MVC ko'pincha "Massive View Controller" deb nomlangan muammoni keltirib chiqaradi, ammo bu etarli darajada murakkab bo'lgan ilovalarda faqat sodir bo'ladi va jiddiy narsaga aylanadi.

View Controller-ni yanada boshqariladigan qilish uchun ishlab chiqaruvchidan foydalanadigan ba'zi usullar mavjud. Ba'zi misollar:

  • VC mantiqini boshqa sinflar uchun ajratish, masalan, jadvalni tuzish uslubi ma'lumotlarini ishlatib, jadvalni ko'rish usullari ma'lumot manbasi va boshqa fayllar uchun vakil.
  • Mas'uliyatni kompozitsiyalar bilan yanada aniqroq ajratishni yarating (masalan, VC ni bolalar ko'rish nazoratchilariga ajratish).
  • VC-da navigatsiya mantig'ini amalga oshirish uchun javobgarlikni olib tashlash uchun koordinator dizayn naqshidan foydalaning
  • Mantiqni qamrab oladigan va ma'lumotlar modelini oxirgi foydalanuvchiga taqdim etiladigan ma'lumotlarni aks ettiradigan ma'lumotlarning chiqishiga aylantiradigan DataPresenter doka sinfidan foydalaning.

MVC va MVP

Qanday qilib ko'rishingiz mumkin MVP diagrammasi MVC ga juda o'xshash

MVC oldinga bir qadam edi, lekin u hali ham ba'zi narsalar haqida yo'qligi yoki sukut saqlanishi bilan belgilandi.

Shu bilan birga, Umumjahon Internet o'sib bordi va ishlab chiquvchilar jamoasida ko'p narsalar rivojlandi. Masalan, dasturchilar Ajax-dan foydalanishni boshladilar va bir vaqtning o'zida butun HTML sahifaning o'rniga sahifalarning qismlarini yuklaydilar.

MVC-da, menejerning View (yo'qligi) ning aniq bajarilishini bilmasligi kerakligini anglatadigan hech narsa yo'q deb o'ylayman.

HTML View qatlamining bir qismi edi va ko'p holatlar fuck kabi soqov edi. Ba'zi hollarda, u faqat foydalanuvchidan voqealarni oladi va GUI-ning vizual tarkibini namoyish etadi.

Veb-sahifalarning bir qismlarini yuklashni boshlaganligi sababli, ushbu segmentatsiya View holatini saqlab qolish va taqdimot mantiqiy javobgarligini ajratish uchun ko'proq ehtiyojga olib keldi.

Taqdimot mantig'i UI qanday ko'rsatilishini va UI elementlarining o'zaro ta'sirini boshqaradigan mantiqdir. Bunga misol yuklash indikatori qachon ko'rsatilishi / jonlantirishi va qachon ko'rsatishi / jonlantirishi kerakligini boshqarish mantig'i.

MVP va MVVM-da View Layer mantiqsiz yoki aqlsiz holda soqov bo'lishi kerak, va iOS-da View Controller View Layer-ning bir qismi bo'lishi kerak. Ko'rinishning soqov ekanligi shunchaki taqdimot mantig'i View qatlamidan tashqarida qolishini anglatadi.

MVC-ning muammolaridan biri shundaki, u taqdimot mantig'ining qaerda turishi aniq emas. U shunchaki sukut saqlamoqda. Taqdimot mantig'i View qatlamida yoki Model qatlamida bo'lishi kerakmi?

Agar Modelning roli shunchaki "xom" ma'lumotlarni taqdim etish bo'lsa, bu View-dagi kod quyidagicha bo'lishini anglatadi:

Quyidagi misolni ko'rib chiqing: bizda ism va familiyasi bo'lgan foydalanuvchi bor. Ko'rish oynasida foydalanuvchi ismini "Familiya, ism" (masalan, "Flores, Tiago") sifatida ko'rsatishimiz kerak.

Agar Modelning roli "xom" ma'lumotlarni taqdim etish bo'lsa, bu View-dagi kod quyidagicha bo'lishini anglatadi:

let firstName = userModel.getFirstName ()
letName = userModel.getLastName ()
nameLabel.text = familiya + "," + birinchi ism

Demak, UI UI mantig'ini boshqarish uchun View javobgar bo'ladi. Ammo bu UI mantig'ini birlik sinovini imkonsiz qiladi.

Boshqa yondashuv - bu Modelga faqatgina ko'rinishi kerak bo'lgan ma'lumotlarni ochib berish, har qanday biznes mantig'ini View-dan yashirish. Ammo keyin biz ikkala biznes va UI mantig'ini boshqaradigan Modellar bilan yakunlaymiz. Bu birlikni sinab ko'rishi mumkin edi, ammo keyin Model to'liq ko'rinishga ega bo'lib, yakunlanadi.

let name = userModel.getDisplayName ()
nameLabel.text = ism

MVP bu haqida aniq va taqdimot mantig'i Taqdimotchi qatlamida qoladi. Bu Presenter qatlamining sinovga layoqatliligini oshiradi. Endi Model va Taqdimotchi qatlamini sinab ko'rish oson.

Odatda MVP dasturlarida View interfeys / protokol orqasida yashiringan va Taqdimotchida UIKit-ga havolalar bo'lmasligi kerak.

Yodda tutish kerak bo'lgan yana bir narsa - bu o'tkinchi bog'liqliklar.

Agar Boshqaruvchida qaramlik sifatida Biznes-layner bo'lsa va Business Layer-da qaramlik sifatida ma'lumotlarga ega bo'lish qatlami bo'lsa, u holda Boshqaruvchida ma'lumotlar kirish sathiga o'tish tranzit bog'liqligi mavjud. MVP dasturlari odatda barcha sathlar o'rtasida kontrakt (protokol) dan foydalanganligi sababli u o'tkinchi bog'liqlikka ega emas.

Turli xil qatlamlar turli sabablarga ko'ra va har xil narxlarda o'zgaradi. Shunday qilib, siz qatlamni o'zgartirganda, boshqa qatlamlarda ikkinchi darajali ta'sir / muammolar paydo bo'lishini istamaysiz.

Protokollar sinflarga qaraganda ancha barqaror. Protokollar va kontraktlarda bajarilish tafsilotlari mavjud emas, shuning uchun boshqa sathlarga ta'sir qilmasdan sathni amalga oshirish tafsilotlarini o'zgartirish mumkin.

Shunday qilib, shartnomalar (protokollar) qatlamlar o'rtasida o'zaro bog'liqlikni keltirib chiqaradi.

MVP - MVVM

MVVM diagrammasi

MVP va MVVM o'rtasidagi asosiy farqlardan biri shundaki, MVP-da Taqdimotchi View bilan interfeyslar orqali aloqa qiladi va MVVM-da View ma'lumotlar va voqealarning o'zgarishiga yo'naltirilgan.

MVP-da biz interfeys / protokollardan foydalangan holda Presenter va View o'rtasida qo'l bilan bog'laymiz.
MVVM-da biz RxSwift, KVO kabi narsalarni ishlatib ma'lumotlarni avtomatik bog'laymiz yoki generiklar va yopadigan mexanizmlardan foydalanamiz.

MVVM-da, hatto ViewModel va View o'rtasidagi shartnoma (masalan, java interfeysi / iOS protokoli) ham kerak emas, chunki biz odatda Observer Design Pattern orqali aloqa qilamiz.

MVP Delegate Pattern-dan foydalanadi, chunki Taqdimotchi qatlami vakillari View Layer-ga buyurtma berishadi, shuning uchun u faqat interfeys / protokol imzosi bo'lsa ham View haqida biron bir ma'lumotga ega bo'lishi kerak. Xabarnoma markazi va TableView delegatlari o'rtasidagi farq haqida o'ylang. Xabarnoma markazida aloqa kanalini yaratish uchun interfeyslarga ehtiyoj bo'lmaydi, lekin TableView Delegates sinflar bajarishi kerak bo'lgan protokoldan foydalanadi.

Yuklash indikatorining taqdimot mantig'ini o'ylab ko'ring. MVP-da taqdimotchi ViewProtocol.showLoadingIndicator-ni amalga oshiradi. MVVM-da ViewModel-da yuklash xususiyati bo'lishi mumkin. Avtomatik bog'laydigan View qatlami ushbu xususiyat o'zgarganda va yangilanganda aniqlaydi. MVP MVVM-dan ko'ra muhimroqdir, chunki Taqdimotchi buyruq beradi.

MVVM to'g'ridan-to'g'ri buyurtmalarga qaraganda ma'lumotlarning o'zgarishi haqida ko'proq ma'lumotga ega va biz ma'lumotlar o'zgarishi va ko'rish yangilanishlari o'rtasida bog'liqlik qilamiz. Agar MxM bilan birgalikda RxSwift va funktsional reaktiv dasturlash paradigmasidan foydalansak, biz kodni yanada ahamiyatsiz va deklarativ qildik.

MVVM-ni MVP-ga qaraganda osonroq sinash osonroq, chunki MVVM tarkibiy qismlar orasidagi ma'lumotlarni uzatiladigan tarzda uzatuvchi Observer Design Pattern-dan foydalanadi.
Shunday qilib, biz View va Presenter o'rtasidagi aloqani sinab ko'rish uchun chaqiriladigan usullarni yaratmasdan, ikkita ob'ektni taqqoslash orqali ma'lumotlarning o'zgarishini ko'rib chiqish orqali sinab ko'rishimiz mumkin.

PS: Men maqolada juda ko'p yangiliklarni yangiladim, shuning uchun uni uch qismga bo'lish kerak edi. Uchinchi qismni bu erda o'qishingiz mumkin.

Ikkinchi qism shu bilan tugaydi. Barcha mulohazalar qabul qilinadi. Uchinchi qismda VIPER, VIP, Reaktiv dasturlash, Savdo-sotiq, cheklovlar va kontekstni boshqarish haqida so'z boradi.

O'qiganingiz uchun tashakkur! Agar sizga ushbu maqola yoqsa, iltimos, qarsak chaling
shuning uchun uni boshqalar ham o'qiydilar :)