Сәйкес iOS архитектурасын қалай таңдауға болады (2 бөлім)

MVC, MVP, MVVM, VIPER немесе VIP

Бірінші бөліммен мына жерден таныса аласыз.

IOS архитектурасының ең маңыздысы

Қысқаша шолу.

MVC

MVC қабаттары келесідей:

М: іскери логика, желілік деңгей және мәліметтерге қол жеткізу деңгейі

V: UI деңгейі (UIKit нысандары, сюжеттік суреттер, Xibs)

C: модель мен көрініс арасындағы делдалдықты үйлестіреді.

MVC-ді түсіну үшін біз оны ойлап тапқан контексті түсінуіміз керек. MVC веб-дамудың ескі күндерінде «Views» мәртебесі болмаған кезде ойлап табылған. Бұрынғы кезде веб-сайтта визуалды өзгеріс қажет болған кезде браузер барлық HTML-ді қайта жүктейді. Ол кезде көзқарас күйі сақталып, сақталуда деген ой болған жоқ.

Мысалы, HTML-файлдарды, PHP-ді және мәліметтер базасына қатынасуды қолданған бірнеше жасаушылар болды. Сондықтан MVC-тің негізгі мотивациясы көру деңгейін модель деңгейінен бөлу болды. Бұл модель деңгейінің сыналғыштығын арттырды. MVC-де көрініс пен модель қабаттары бір-бірін білмеуі керек. Мұны істеу үшін контроллер деп аталатын аралық қабат ойлап табылды. Бұл қолданылған SRP болды.

MVC циклының мысалы:

  1. Көрініс деңгейіндегі қолданушы әрекеті / қолданушы оқиғасы (мысалы, «Жаңарту әрекеті») іске қосылады және бұл әрекет контроллерге жеткізіледі
  2. Деректерді модель деңгейіне жіберетін контроллер
  3. Қайтарылған деректерді контроллерге модельдеу
  4. Контроллер көрініс өзінің күйін жаңа деректермен жаңартады дейді
  5. Жаңарту күйін қарау

Apple MVC

IOS-та View Controller UIKit және өмірлік цикл көрінісімен біріктірілген, сондықтан бұл таза MVC емес. Алайда, MVC анықтамасында контроллер көріністі немесе модельдің нақты орындалуын біле алмайды деген ештеңе жоқ. Оның негізгі мақсаты - модель деңгейінің міндеттерін көру деңгейінен бөліп алу, сондықтан біз оларды қайта қолданып, модель деңгейін оқшаулап тексере аламыз.

ViewController көріністі қамтиды және модельге иелік етеді. Мәселе мынада, біз контроллер кодын да, қарау кодын да ViewController-ке жазып жатырмыз.

MVC көбінесе Massive View Controller ақаулығын тудырады, бірақ ол тек жеткілікті күрделілігі бар қосымшаларда пайда болады және маңызды бизнеске айналады.

Қарау контроллерін түсінікті ету үшін әзірлеуші ​​қолдана алатын бірнеше әдіс бар. Кейбір мысалдар:

  • Басқа сыныптарға арналған VC логикасын шығарыңыз, мысалы, кестені қарау әдістерінің дереккөздері және делегаттар дизайны үлгісін қолданып, басқа файлдар үшін делегаттар.
  • Композицияға қатысты жауапкершіліктің неғұрлым айқын бөлігін жасаңыз (мысалы, VC-ді балалар көрінісін басқару элементтеріне бөлу).
  • Виртуалды контроллерде навигация логикасын енгізу жауапкершілігін жою үшін үйлестірушінің дизайн үлгісін пайдаланыңыз
  • Логиканы жинақтайтын және деректер моделін соңғы пайдаланушыға ұсынылатын деректерді көрсететін мәліметтер шығысына түрлендіретін DataPresenter орағыш класын қолданыңыз.

MVC және MVP

MVP-ден диаграмманы көріп отырғаныңыздай, MVC өте ұқсас

MVC алға қадам болды, бірақ ол әлі де болмауымен немесе кейбір нәрселер туралы үнсіздікпен белгіленді.

Осы уақыт аралығында Дүниежүзілік Интернет дамып, көптеген жобалаушылар қауымдастығында дамыды. Мысалы, бағдарламашылар Ajax-ты қолдана бастады және бірден бүкіл HTML парақтың орнына тек беттердің бөліктерін жүктеді.

MVC-де, менің ойымша, контроллер View-тың нақты орындалуын білмеуі керек деген белгі жоқ (жоқ).

HTML көру қабатының бөлігі болды, ал көптеген жағдайлар бұл ақымақ болды. Кейбір жағдайларда ол тек қолданушыдан оқиғаларды қабылдайды және GUI-дің визуалды мазмұнын көрсетеді.

Веб-беттердің бөліктері бөліктерге жүктелгендіктен, бұл сегментация көру күйінің сақталуына және презентация логикасы үшін жауапкершілікті бөлуге үлкен қажеттілікке әкелді.

Презентация логикасы - бұл қолданушы интерфейсін қалай көрсету керектігін және пайдаланушы интерфейсінің элементтерінің бір-бірімен өзара әрекеттесуін басқаратын логика. Мысал - жүктеу индикаторы қашан көрсетіле бастайтынын / анимацияланатындығын және қашан көрсетілмейтін / жандандырылатынын басқару логикасы.

MVP және MVVM-де қарау деңгейі логикалық немесе интеллектілік болмайтындай соншалықты сыпайы болуы керек, ал iOS-та қарау контроллері көрініс деңгейінің бөлігі болуы керек. View-дің мылқау екендігі тіпті презентация логикасының View жазықтығынан тыс қалуын білдіреді.

MVC проблемаларының бірі - презентация логикасының қайда кетуі керек екендігі түсініксіз. Ол бұл туралы жай ғана үнсіз. Презентация логикасы көру жазықтығында немесе модель жазықтығында болуы керек пе?

Егер модель рөлі тек «шикі деректерді» беру болса, онда көріністегі код келесідей болады:

Келесі мысалды қарастырайық: бізде аты-жөні бар пайдаланушы бар. Көріністе біз пайдаланушының атын «Тегі, аты» ретінде көрсетуіміз керек (мысалы, «Флорес, Тиаго»).

Егер модельдің рөлі «шикі» деректерді беру болса, онда көріністегі код келесідей болады:

firstName = userModel.getFirstName () letName = userModel.getLastName () nameLabel.text = Тегі + “,“ + Аты

Бұл қолданушы интерфейсінің логикасын өңдеу View-ге жүктелгенін білдіреді. Алайда, бұл қолданушы интерфейсінің логикасын тестілеу мүмкін емес етеді.

Басқа тәсіл - модельге тек көрсетілуі керек деректерді көрсетуге мүмкіндік беру және бизнес логикасын көруден жасыру. Бірақ бізде бизнес логикасын да, қолданушы интерфейсінің логикасын да басқаратын модельдер бар. Бұл сыналатын объект болар еді, бірақ содан кейін модель жанама түрде тәуелді болады.

name = userModel.getDisplayName () nameLabel.text = аты болсын

Бұл MVP үшін түсінікті және презентация логикасы презентация деңгейінде қалады. Бұл жүргізуші деңгейінің сыналғыштығын арттырады. Енді модель мен баяндауыш қабатын еш қиындықсыз тексеруге болады.

Әдетте MVP іске асыруларында көрініс интерфейс / протоколдың артында жасырылады және презентацияда UIKit сілтемелері болмауы керек.

Тағы бір айта кететін нәрсе - транзитивті тәуелділіктер.

Егер контроллерде тәуелділік ретінде іскери деңгей болса, ал іскери деңгейде тәуелділік ретінде деректерге қол жетімділік деңгейі болса, контроллерде мәліметтерге қол жеткізу деңгейінде транзиттік тәуелділік болады. MVP іске асырулары әдетте барлық деңгейлер арасындағы келісімшартты (хаттаманы) қолданатындықтан, өтпелі тәуелділіктер болмайды.

Әр түрлі қабаттар әр түрлі себептермен және жылдамдықпен өзгереді. Егер сіз бір деңгейге ауыссаңыз, бұл екінші деңгейлерде екінші деңгейлі эффекттер мен проблемалар тудырмауы керек.

Хаттамалар сыныптарға қарағанда тұрақты. Журналдарда іске асырудың ешқандай егжей-тегжейі жоқ және келісімшарттармен байланыспаған. Демек, басқа деңгейлерге әсер етпей, бір деңгейдің іске асырылу бөлшектерін өзгертуге болады.

Келісімшарттар (хаттамалар) қабаттар арасында ажырау жасайды.

MVP және MVVM

MVVM диаграммасы

MVP мен MVVM арасындағы негізгі айырмашылықтардың бірі - MVP-де презентация көрініске интерфейс жасайды, ал MVVM-де көрініс мәліметтер мен оқиғалардың өзгеруіне бағытталған.

MVP-де біз интерфейстерді / протоколдарды қолданып, презентация мен көрініс арасындағы қолмен сілтеме жасаймыз. MVVM-де біз автоматты түрде деректерді RxSwift, KVO немесе генериктері бар және жабылатын механизммен байланыстырамыз.

MVVM-де бізге ViewModel және View арасындағы келісімшарттың қажеті жоқ (мысалы, Java интерфейсі / iOS хаттамасы), өйткені біз әдетте Observer Design Pattern арқылы байланысамыз.

MVP делегат үлгісін қолданады, өйткені презентацияшы деңгей командаларды қарау деңгейіне береді. Сондықтан ол интерфейс / протокол қолтаңбасы болса да, көрініс туралы бір нәрсе білуі керек. Хабарландыру орталығы мен TableView делегаттарының арасындағы айырмашылық туралы ойланыңыз. Хабарландыру орталығына байланыс арнасын құру үшін ешқандай интерфейс қажет емес. Алайда, TableView делегаттары сыныптар жүзеге асыруы керек хаттаманы қолданады.

Зарядтау индикаторының ұсыну логикасы туралы ойланыңыз. MVP-де баяндамашы ViewProtocol.showLoadingIndicator бағдарламасын іске қосады. MVVM-де ViewModel-де isLoading қасиеті болуы мүмкін. Көрініс қабаты бұл қасиеттің өзгеріп, жаңарғанын тану үшін автоматты түрде байланыстыруды қолданады.MVP MVVM-ге қарағанда тартымды, себебі баяндамашы командаларды шығарады.

MVVM тікелей бұйрыққа қарағанда деректердің өзгеруіне қатысты және біз жаңартуларды қарау үшін деректердің өзгеруін байланыстырамыз. Біз MVVM-мен бірге RxSwift пен функционалды реактивті бағдарламалау парадигмасын қолданған кезде біз кодты одан да тартымды және декларативті етіп жасадық.

MVVM-ді тексеру MVP-ге қарағанда оңайырақ, өйткені MVVM-де компоненттер арасындағы деректерді ажыратылған тәртіппен беретін Observer Design Pattern қолданылады. Сонымен, біз көрініс пен таныстырушы арасындағы байланысты тексеруге арналған әдіс шақыруларын келемеждеудің орнына, тек екі объектіні салыстыру арқылы деректердегі өзгерістерге қарап тест жасай аламыз.

PS: Мен оны көп өсіретін затқа бірнеше жаңартулар енгіздім. Сондықтан оны үш бөлікке бөлу қажет болды. Үшінші бөлімді мына жерден оқи аласыз.

Екінші бөлім осында аяқталады. Барлық пікірлер қабылданады. Үшінші бөлім VIPER, VIP, реактивті бағдарламалау, сауда-саттық, шектеулер және контексттік сезім туралы.

Оқығандарыңызға рахмет! Егер сізге бұл мақала ұнаған болса, басқалар да оқи алатындай қол соғыңыз .