Тийиштүү iOS архитектурасын кантип тандаса болот (2-бөлүк)

MVC, MVP, MVVM, VIPER же VIP

Биринчи бөлүктү бул жерден көрө аласыз.

Эң маанилүү iOS архитектурасы

Кыскача сереп.

MVC

MVC катмарлары төмөнкүчө:

М: бизнес логикасы, тармактык катмар жана маалыматка жетүү катмары

V: UI деңгээли (UIKit объектилери, сюжеттик такталар, Xibs)

C: Модель менен көздүн ортосундагы ортомчулукту координациялайт.

MVCти түшүнүү үчүн ал кандай шартта иштелип чыккандыгын түшүнүшүбүз керек. MVC Вебди иштеп чыгуунун эски күндөрүндө Көрүнүштөр статусу жок болгон учурда ойлоп табылган. Илгерки мезгилдерде, веб-сайтта визуалдык өзгөрүүлөр керек болгондо, браузер бардык 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де көрүү катмары эч кандай логикага жана интеллектке ээ болбогондуктан, көзкаранды катмарынын курамына кириши керек. View дудук экендиги презентация логикасы да View тегиздигинен тышкары бойдон кала берерин билдирет.

MVC көйгөйлөрүнүн бири - презентация логикасы кайда кетиши керек экендиги белгисиз. Ал жөн эле унчукпайт. Презентация логикасы көрүү тегиздигинде же модель тегиздигинде болушу керекпи?

Эгерде моделдин ролу "чийки маалыматтарды" гана камсыз кылуу болсо, анда коддун көрүнүшү төмөнкүдөй:

Төмөнкү мисалды карап көрөлү: Бизде аты жана фамилиясы бар колдонуучу бар. Колдонуучунун атын "Фамилия, Аты" (мисалы, "Флорес, Тиаго") катары көрсөтүүбүз керек.

Эгерде моделдин ролу "чийки маалыматтарды" берүү болсо, анда коддун көрүнүшү төмөнкүдөй:

letName = userModel.getFirstName () letName = userModel.getLastName () nameLabel.text = Фамилия + “,“ + Аты

Бул колдонуучунун интерфейсинин логикасын башкаруу View'дун милдети экендигин билдирет. Бирок, бул колдонуучу интерфейсинин логикасын бирдиктүү тестирлөөнү жүргүзүүгө мүмкүн эмес.

Башка ыкма - бул модель көрсөтүлүшү керек болгон маалыматтарды гана көрсөтүп, бизнес логикасын көздөн жашыруу. Бирок андан кийин бизнес логикасын дагы, колдонуучу интерфейсинин дагы логикасын башкарган моделдерибиз бар. Бул текшерилүүчү жак болмок, бирок андан кийин модель көзкаранды көзкаранды эмес.

name = userModel.getDisplayName () nameLabel.text = аты

Бул MVP үчүн түшүнүктүү жана презентация логикасы алып баруучунун деңгээлинде калат. Бул алып баруучунун деңгээлинин тесттүүлүгүн жогорулатат. Эми моделди жана алып баруучунун катмарын эч кандай көйгөйсүз текшерсе болот.

Адатта, MVP ишке ашырылышында көрүнүш интерфейстин / протоколдун артында жашырылат жана алып баруучуда UIKitке шилтемелер болбошу керек.

Дагы бир белгилей кетүүчү нерсе, өтмө көзкарандылык.

Эгерде контроллер көз карандылык катары бизнес катмарына ээ болсо жана бизнес катмар көз карандылык катарында маалыматка жетүү катмарына ээ болсо, контроллер маалыматка жетүү катмарына өтмө көз карандылыкка ээ. MVP ишке ашыруусу адатта бардык деңгээлдердин ортосунда келишимди (протоколду) колдонгондуктан, транзиттик көзкарандылыктар жок.

Ар кандай катмарлар да ар кандай себептерден жана ар кандай ылдамдыкта өзгөрүлөт. Демек, сиз бир деңгээлди которсоңуз, анда башка деңгээлдерде экинчи эффекттер / көйгөйлөр жаралбашы керек.

Протоколдор класстарга караганда туруктуу. Журналдарда ишке ашыруунун деталдары жок жана келишимдер менен байланыштырылган эмес. Демек, башка деңгээлдерге таасир этпестен, бир деңгээлдеги ишке ашыруунун деталдарын өзгөртүүгө болот.

Келишимдер (протоколдор) катмарлардын ортосунда ажыроону жаратат.

MVP vs 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 түздөн-түз буйруктарга караганда маалыматтарды өзгөртүү жөнүндө көбүрөөк маалымат берет жана биз жаңыланууларды көрүү үчүн маалыматтардын өзгөрүүлөрүн байланыштырабыз. RxSwiftти жана функционалдык реактивдүү программалоо парадигмасын MVVM менен бирге колдонгондо, биз кодду анча таасирдүү эмес жана декларативдүү кылдык.

MVVMди текшерүү MVPге караганда оңой, анткени MVVM Observer Design Pattern колдонот, ал компоненттердин ортосунда маалыматтарды ажыратып бөлүштүрөт. Ошентип, көрүнүш менен алып баруучунун ортосундагы байланышты текшерүү үчүн ыкма чакырыктарын шылдыңдоонун ордуна, эки объектини салыштырып, маалыматтардын өзгөрүүсүн карап гана текшере алабыз.

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

Экинчи бөлүк ушул жерде аяктайт. Бардык пикирлер кабыл алынат. Үчүнчү бөлүк VIPER, VIP, реактивдүү программалоо, соода-сатык, чектөөлөр жана контексттик сезим жөнүндө.

Окуганыңыз үчүн рахмат! Эгер сизге бул макала жаккан болсо, анда башкалар да окушу үчүн, кол чаап коюңуз please