Hvernig á að velja viðeigandi iOS arkitektúr (2. hluti)

MVC, MVP, MVVM, VIPER eða VIP

Þú getur haft samráð við fyrsta hluta hér.

Mikilvægustu IOS arkitektúrin

Stutt yfirlit.

MVC

MVC lögin eru sem hér segir:

M: viðskiptarökfræði, netlag og gagnaaðgangslag

V: UI stig (UIKit hlutir, storyboards, Xibs)

C: Samhæfir miðlun milli líkans og skoðunar.

Til að skilja MVC verðum við að skilja samhengið sem það var fundið upp í. MVC var fundin upp í gömlu vefþróunardögunum þegar Views höfðu enga stöðu. Í gamla daga endurhladdar vafrinn allt HTML í hvert skipti sem við þurfum sjónræna breytingu á vefsíðunni. Á þeim tíma var engin hugmynd um að útsýnisstaðan væri viðvarandi og vistuð.

Til dæmis voru nokkrir forritarar sem notuðu sömu HTML skrár, PHP og aðgang að gagnagrunni. Svo aðal hvatning MVC var að aðgreina útsýnisstig frá líkanstigi. Þetta jók prófanleika líkanstigs. Sagt að í MVC ætti útsýni og líkanalög ekki að vita um hvort annað. Til að gera þetta mögulegt var fundið upp millilag sem kallast stjórnandi. Þetta var SRP sem beitt var.

Dæmi um MVC hringrás:

  1. Aðgerð frá notanda / notendaviðburður á útsýnisstigi (t.d. „uppfærsla aðgerð“) er hrundið af stað og þessari aðgerð er komið til stjórnandans
  2. Stjórnandi sem sendir gögn á líkanstig
  3. Líkaðu skilað gögnum til stjórnandans
  4. Stjórnandi segir að útsýnið muni uppfæra stöðu sína með nýju gögnunum
  5. Skoða uppfæra stöðu þess

Apple MVC

Í IOS er útsýnisstýringin ásamt UIKit og líftímaskjánum svo það er ekki hreinn MVC. Hins vegar í skilgreiningu MVC er ekkert sem segir að stjórnandinn geti ekki vitað sýnina eða fyrirmyndar sértæka útfærslu. Megintilgangur þess er að aðskilja ábyrgð líkanstigsins frá útsýnisstiginu svo að við getum endurnýtt þau og prófað líkanstigið í einangrun.

ViewController inniheldur útsýnið og á líkanið. Vandamálið er að við erum að skrifa bæði stjórnarkóðann og útsýnisnúmerið til ViewController.

MVC veldur oft því sem kallað er Massive View Controller vandamálið, en það kemur aðeins fyrir í forritum með nógu flókið og verður alvarlegt fyrirtæki.

Það eru nokkrar aðferðir sem verktaki getur notað til að gera View Controller skýrari. Nokkur dæmi:

  • Dragðu út VC rökfræði fyrir aðra flokka, svo sem gagnagjafa töfluútsýnisaðferða og sendu fyrir aðrar skrár með því að nota mynstur fulltrúa.
  • Búðu til skýrari sundurliðun á samsetningarábyrgð (t.d. að skipta VC í eftirlit með barnaútsýni).
  • Notaðu hönnunarmynstur samræmingaraðila til að fjarlægja ábyrgð á útfærslu leiðsögufræðinnar í sýndarstýringunni
  • Notaðu DataPresenter umbúðarflokk sem hylur rökfræði og breytir gagnalíkaninu í gagnaútgang sem táknar gögnin sem kynnt eru fyrir endanotanda.

MVC á móti MVP

Eins og sjá má skýringarmynd MVP er MVC mjög svipað

MVC var skref fram á við, en það einkenndist samt af fjarveru eða þögn um suma hluti.

Í millitíðinni óx veraldarvefurinn og margt þróaðist í verktakasamfélaginu. Forritarar fóru til dæmis að nota Ajax og hlóðu aðeins hlutum síðna í stað allrar HTML síðunnar í einu.

Í MVC, að mínu mati, er ekkert sem bendir til þess að stjórnandinn ætti ekki að þekkja sértæka útfærslu á View (fjarveru).

HTML var hluti af útsýnislaginu og mörg mál voru svo heimskuleg. Í sumum tilvikum fær það bara viðburði frá notandanum og birtir sjónrænt efni GUI.

Þegar hlutar vefsíðanna voru hlaðnir í hluta leiddi þessi skipting til þess að sjónarsviðið varðveittist og meiri þörf var á að aðgreina ábyrgð á kynningarrökfræðinni.

Kynningarlógík er rökfræðin sem stýrir því hvernig notendaviðmótið birtist og hvernig notendaviðmótaþættir hafa samskipti sín á milli. Dæmi er stjórnlógíkin um hvenær hleðsluvísir ætti að byrja að sýna / hreyfa og hvenær hann ætti að hætta að sýna / lífga upp á.

Í MVP og MVVM ætti útsýnislagið að vera svo fíflalegt að það innihaldi enga rökfræði eða greind og í iOS ætti útsýnisstýringin að vera hluti af útsýnislaginu. Sú staðreynd að Útsýni er mállaus þýðir að jafnvel kynningarlógíkin helst utan við View planið.

Eitt af vandamálunum við MVC er að ekki er ljóst hvert kynningarfræðin ætti að fara. Hann er einfaldlega þögull um það. Ætti kynningarrökfræði að vera á útsýnisstigi eða á fyrirmyndarstigi?

Ef hlutverk líkansins er að veita aðeins „hráu gögnin“ þýðir það að kóðinn í myndinni er sem hér segir:

Lítum á eftirfarandi dæmi: Við erum með notanda með fornafn og eftirnafn. Að því er varðar þurfum við að sýna notendanafnið sem „Eftirnafn, fornafn“ (t.d. „Flores, Tiago“).

Ef hlutverk líkansins er að veita „hráu“ gögnin þýðir það að kóðinn í myndinni er sem hér segir:

let firstName = userModel.getFirstName () let lastName = userModel.getLastName () nameLabel.text = Eftirnafn + “,“ + First Name

Þetta þýðir að það er á ábyrgð View að meðhöndla rökfræði notendaviðmótsins. Þetta gerir það hins vegar ómögulegt að eininga próf á rökfræði notendaviðmótsins.

Hin aðferðin er að láta líkanið aðeins sýna gögnin sem þarf að sýna og fela viðskiptarökfræði fyrir sjónarhorninu. En þá höfum við módel sem höndla bæði viðskiptarökfræði og notendaviðmótarökfræði. Það væri prófanleg eining, en þá er líkanið óbeint útsýni háð.

láta nafn = userModel.getDisplayName () nameLabel.text = nafn

Þetta er MVP ljóst og kynningarrökfræðin er áfram á kynningarstigi. Þetta eykur prófanleika kynnarstigsins. Nú er hægt að prófa líkanið og kynningarlagið án vandræða.

Venjulega í MVP útfærslum er útsýnið falið á bakvið viðmót / samskiptareglur og það ætti ekki að vera tilvísun í UIKit í kynninum.

Annað sem þarf að hafa í huga er tímabundið ósjálfstæði.

Ef stjórnandinn hefur viðskiptalag sem ósjálfstæði og viðskiptalagið hefur gagnalagslag sem ósjálfstæði hefur stjórnandinn tímabundið ósjálfstæði gagnagagnalagsins. Þar sem MVP útfærslurnar nota venjulega samning (siðareglur) milli allra stiga eru engin tímabundin háð.

Mismunandi lögin breytast líka af mismunandi ástæðum og á mismunandi hraða. Þannig að ef þú skiptir um eitt stig, þá á þetta ekki að valda aukaatriðum / vandamálum á hinum stigunum.

Samskiptareglur eru stöðugri en flokkar. Annálarnar innihalda engar upplýsingar um framkvæmdina og eru ekki tengdir samningunum. Þess vegna er mögulegt að breyta útfærsluatriðum eins stigs án þess að hafa áhrif á önnur stig.

Samningarnir (siðareglur) skapa aftengingu milli laga.

MVP vs MVVM

MVVM skýringarmynd

Einn helsti munurinn á MVP og MVVM er að í MVP tengir kynnirinn við útsýnið og í MVVM beinist útsýnið að gögnum og breytingum á atburði.

Í MVP búum við til handvirkan tengil milli kynningaraðila og útsýnis með því að nota tengi / samskiptareglur. Í MVVM framkvæmum við sjálfvirka gagnabindingu með RxSwift, KVO eða vélbúnaði með samheitalyfjum og lokunum.

Í MVVM þurfum við ekki einu sinni samning (t.d. Java tengi / iOS samskiptareglur) milli ViewModel og View, þar sem við höfum venjulega samskipti um Observer Design Pattern.

MVP notar umboðsmynstrið vegna þess að kynningarlagið framselur skipanir á útsýnislagið. Þess vegna þarf hann að vita eitthvað um útsýnið, jafnvel þó að það sé bara viðmót / samskiptareglur undirskrift. Hugsaðu um muninn á tilkynningarmiðstöðinni og TableView fulltrúum. Tilkynningarmiðstöðin þarf engin tengi til að búa til samskiptarás. Fulltrúar TableView nota þó siðareglur sem bekkirnir ættu að innleiða.

Hugsaðu um kynningarrökfræði hleðsluvísis. Í MVP keyrir kynnirinn ViewProtocol.showLoadingIndicator. Í MVVM kann að vera til isLoading eign í ViewModel. Útsýnislagið notar sjálfvirka gagnabinding til að þekkja þegar þessi eign breytist og uppfærir sig. MVP er meira sannfærandi en MVVM vegna þess að kynnirinn gefur út skipanir.

MVVM snýst meira um gagnabreytingar en beinar pantanir og við tengjum gagnabreytingar til að skoða uppfærslur. Þegar við notum RxSwift og hagnýtt viðbragðsforritunarfyrirmynd ásamt MVVM höfum við gert kóðann enn minna sannfærandi og skýrari.

MVVM er auðveldara að prófa en MVP vegna þess að MVVM notar Observer Design Pattern sem flytur gögn milli íhluta á aftengdan hátt. Þannig að við getum prófað með því að skoða aðeins breytingar á gögnum með því að bera saman hlutina tvo, frekar en að hæðast að aðferðarköllunum til að prófa samskiptin milli útsýnisins og kynnisins.

PS: Ég gerði nokkrar uppfærslur á hlutnum sem lét það vaxa mikið. Það var því nauðsynlegt að skipta því í þrjá hluta. Þú getur lesið þriðja hlutann hér.

Hluti tvö endar hér. Öll viðbrögð eru vel þegin. Hluti þrír fjallar um VIPER, VIP, viðbragðsforritun, afgreiðslu, takmarkanir og samhengisvitund.

Þakka þér fyrir lesturinn! Ef þú hafðir gaman af þessari grein, vinsamlegast klappaðu svo aðrir geti lesið hana líka :)