Wéi wielt Dir déi entspriechend iOS Architektur (Deel 2)

MVC, MVP, MVVM, VIPER oder VIP

Dir kënnt en Deel hei consultéieren.

Déi wichtegst iOS Architekturen

E kuerzen Iwwerbléck.

MVC

D'MVC Schichten si wéi folgend:

M: Geschäftslogik, Netzwierkschicht an Datenzougangsschicht

V: UI Niveau (UIKit Objeten, Storyboards, Xibs)

C: Koordinéiert d'Mediatioun tëscht Modell a Sicht.

Fir MVC ze verstoen musse mir de Kontext verstoen an deem et erfonnt gouf. MVC gouf an den alen Webentwécklungsdeeg erfonnt wéi Views kee Status haten. An den alen Deeg lued de Browser all HTML nei wann mir eng visuell Ännerung op der Websäit brauchen. Zu där Zäit war et keng Ahnung datt de Vuezoustand bestänneg a gespuert gëtt.

Zum Beispill waren et e puer Entwéckler déi déiselwecht HTML Dateien, PHP an Datebank Zougang benotzt hunn. Also war d'Haaptmotivatioun vum MVC d'Siichtniveau vum Modellniveau ze trennen. Dëst huet d'Testbarkeet vum Modellniveau erhéicht. Vermeintlech am MVC sollen d'Vue an d'Modellschichten net vunenee wëssen. Fir dëst méiglech ze maachen, gouf eng Tëscheschicht genannt Controller erfonnt. Dëst war de SRP deen ugewannt gouf.

E Beispill vum MVC Zyklus:

  1. Eng Benotzeraktioun / e Benotzerevent am Sichtniveau (z. B. "Aktualiséierungsaktioun") gëtt ausgeléist an dës Aktioun gëtt dem Controller matgedeelt
  2. De Controller deen Daten op de Modellniveau schéckt
  3. Modelléiert déi zréckkomm Daten un de Controller
  4. De Controller seet datt d'Vue säi Status mat den neien Daten aktualiséiert
  5. View Update säi Staat

Apple MVC

Am iOS ass de View Controller mat der UIKit an der Lifecycle Vue gekoppelt, sou datt et net e puren MVC ass. Wéi och ëmmer, et gëtt näischt an der MVC Definitioun fir ze soen datt de Controller net d'Vue oder d'modell spezifesch Ëmsetzung kannt. Säin Haaptzweck ass d'Verantwortung vum Modellniveau vum Sichtniveau ze trennen, sou datt mir se weiderbenotzen an de Modellniveau isoléiert testen.

De ViewController enthält d'Vue an huet de Modell. De Problem ass datt mir de Controller Code an de View Code an de ViewController schreiwen.

MVC verursaacht dacks dat wat de Massive View Controller Problem genannt gëtt, awer et geschitt nëmmen an Apps mat genuch Komplexitéit a gëtt eescht Geschäft.

Et ginn e puer Methoden déi den Entwéckler benotze kann fir de View Controller méi kloer ze maachen. E puer Beispiller:

  • Extraitéiert d'VC Logik fir aner Klassen wéi d'Datenquell vun den Tabellevisungsmethoden an delegéiert fir aner Dateie mat dem Delegéierte Designmuster.
  • Erstellt e méi kloeren Ofbau vu Kompositiounsverantwortung (z. B. de VC an d'Kannervisiounskontrollen deelen).
  • Benotzt de Koordinator Designmuster fir d'Verantwortung fir d'Ëmsetzung vun der Navigatiounslogik am virtuelle Controller ze entfernen
  • Benotzt eng DataPresenter Wrapper-Klass, déi d'Logik ëmkapselt an den Datemodell an d'Datenausgab konvertéiert, déi d'Daten duerstellen, déi dem Endbenutzer presentéiert ginn.

MVC versus MVP

Wéi Dir d'Diagramm vum MVP gesitt, ass MVC ganz ähnlech

De MVC war e Schrëtt no vir, awer et war ëmmer nach duerch e Fehlen oder Rou iwwer verschidde Saachen.

An der Zwëschenzäit ass de World Wide Web wiisst a vill Saachen an der Entwéckler Gemeinschaft entwéckelen. Zum Beispill hunn d'Programméierer ugefaang Ajax ze benotzen an nëmmen Deeler vu Säiten amplaz vun der ganzer HTML Säit gläichzäiteg gelueden.

A MVC, a menger Meenung no, gëtt et keng Indikatioun datt de Controller déi spezifesch Ëmsetzung vu View (Absence) net sollt wëssen.

HTML war Deel vun der Sichtschicht, a vill Fäll waren esou domm. A verschiddene Fäll kritt et just Eventer vum Benotzer a weist de visuellen Inhalt vun der GUI un.

Wéi Deeler vun de Websäiten an Deeler geluede goufen, huet dës Segmentéierung zu der Erhaalung vum Sichtstaat gefouert an e méi groussen Bedierfnes fir Trennung vu Verantwortung fir d'Präsentatiounslogik.

Presentatiounslogik ass d'Logik déi kontrolléiert wéi d'Benotzeroberfläche ugewise gëtt a wéi Benotzerinterfaceelementer matenee interagéieren. E Beispill ass d'Kontrolllogik vu wéini e Luedeindikator soll ufänken ze weisen / animéieren a wéini en ophale soll mat weisen / animéieren.

An MVP an MVVM sollt d'Sichtschicht sou goof sinn datt et keng Logik oder Intelligenz enthält, an am iOS soll de View Controller Deel vun der Sichtschicht sinn. De Fakt datt View domm ass heescht datt och d'Presentatiounslogik ausserhalb vum View Fliger bleift.

Ee vun de Probleemer mam MVC ass datt et net kloer ass wou d'Presentatiounslogik soll goen. Hien ass einfach doriwwer roueg. Sollt d'Presentatiounslogik am Sichtebene sinn oder am Modellfliger?

Wann d'Roll vum Modell nëmmen déi "Roh Daten" ubitt, heescht et datt de Code an der Vue als folgend ass:

Betruecht folgend Beispill: Mir hunn e Benotzer mat engem Vir- a Familljennumm. An der Sicht musse mir de Benotzernumm als "Last Name, First Name" weisen (z. B. "Flores, Tiago").

Wann d'Roll vum Model ass déi "Roh Daten" ze liwweren, heescht et datt de Code an der Sicht wéi follegt ass:

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

Dëst bedeit datt et d'View Verantwortung ass fir d'User Interface Logik ze behandelen. Wéi och ëmmer, dëst mécht et onméiglech d'Benotzerinterface Logik ze testen.

Déi aner Approche ass datt de Modell nëmmen d'Donnéeë weist déi gewise musse ginn an d'Geschäftslogik fir ze gesinn verstoppt. Awer dann hu mir Modeller déi d'Geschäftslogik an d'User Interface Logik behandelen. Et wier eng testbar Entitéit, awer da ass de Modell implizit ofhängeg.

loosst Numm = userModel.getDisplayName () nameLabel.text = Numm

Dëst ass kloer fir de MVP an d'Präsentatiounslogik bleift um Presentateurniveau. Dëst erhéicht d'Testbarkeet vum Presentateurniveau. Elo kann d'Modell an d'Presentator Schicht ouni Probleemer getest ginn.

Normalerweis a MVP Implementatiounen ass d'Vue hannert engem Interface / Protokoll verstoppt an et sollte keng Referenzen op den UIKit am Presentateur sinn.

Eng aner Saach ze beuechten ass déi transitiv Ofhängegkeeten.

Wann de Controller eng Geschäftsschicht als Ofhängegkeet huet an d'Geschäftsschicht eng Datenzougangsschicht als Ofhängegkeet huet, huet de Controller eng transitiv Ofhängegkeet fir d'Datenzougangsschicht. Well d'MVP Implementéierungen normalerweis e Kontrakt (Protokoll) tëscht allen Niveauen benotzen, ginn et keng transitiv Ofhängegkeeten.

Déi verschidde Schichten ännere sech och aus verschiddene Grënn a mat verschiddenen Tauxen. Also wann Dir een Niveau wiesselt, soll et net sekundär Effekter / Probleemer op den aneren Niveauen verursaachen.

Protokoller si méi stabil wéi Klassen. D'Logbicher enthalen keng Implementéierungsdetailer a sinn net mat de Kontrakter verlinkt. Dofir ass et méiglech d'Implementéierungsdetailer vun engem Niveau z'änneren ouni déi aner Niveauen ze beaflossen.

D'Kontrakter (Protokoller) kreéieren eng Entkopplung tëscht de Schichten.

MVP géint MVVM

MVVM Diagramm

Ee vun den Haaptunterschiede tëscht MVP an MVVM ass datt an MVP de Presentateur mat der Sicht interfazéiert, an am MVVM ass d'Vue op Daten an Event Ännerungen fokusséiert.

Am MVP kreéiere mir e manuellen Link tëscht dem Presentateur a Vue mat Interfaces / Protokollen. Am MVVM féiere mir eng automatesch Dateverbindung mat RxSwift, KVO oder e Mechanismus mat Generik a Schließungen.

Am MVVM brauche mir net emol e Kontrakt (zB Java Interface / iOS Protokoll) tëscht ViewModel a View, well mir normalerweis iwwer den Observer Design Muster kommunizéieren.

De MVP benotzt den Delegéierte Muster well d'Presentator Schicht Kommandë delegéiert an d'Sichtschicht. Dofir muss hien eppes iwwer d'Vue wëssen, och wann et nëmmen d'Interface / Protokoll Ënnerschrëft ass. Denkt un den Ënnerscheed tëscht Notifikatiounszentrum an TableView Delegéierten. Den Notifikatiounszentrum brauch keng Interfaces fir e Kommunikatiounskanal ze kreéieren. Wéi och ëmmer, TableView Delegéiert benotzt e Protokoll deen d'Klassen implementéiere sollen.

Denkt un d'Presentatiounslogik vun engem Chargeindikator. Am MVP leeft de Presentator ViewProtocol.showLoadingIndicator. An MVVM kann et en isLoading Besëtz am ViewModel sinn. D'Vue Schicht benotzt automatesch Dateverbindung fir ze erkennen wann dës Eegeschaft ännert an sech selwer aktualiséiert. MVP ass méi iwwerzeegend wéi MVVM well de Presentateur Kommandoen ausgëtt.

MVVM ass méi iwwer Datenännerunge wéi direkt Bestellungen, a mir verknäppe Datenännerunge fir Updates ze gesinn. Wann mir RxSwift an e funktionnelt reaktivt Programméierungsparadigma zesumme mat MVVM benotzen, hu mir de Code nach manner iwwerzeegend a méi deklarativ gemaach.

MVVM ass méi einfach ze testen wéi MVP well MVVM benotzt den Observer Design Muster, deen Daten tëscht Komponenten op eng ofgekoppelt Manéier transferéiert. Also kënne mir testen andeems mir just d'Verännerunge vun den Daten kucken andeems mir déi zwee Objete vergläichen, anstatt mat de Methode rifft de Spott fir d'Kommunikatioun tëscht der Sicht an dem Presentateur ze testen.

PS: Ech hunn e puer Updates zum Element gemaach, déi et vill wuesse gelooss hunn. Et war dofir néideg et an dräi Deeler opzedeelen. Dir kënnt den drëtten Deel hei liesen.

Deel zwee endet hei. All Feedback ass wëllkomm. Den drëtten Deel ass iwwer VIPER, VIP, Reaktiv Programméierung, Ofwiesselungen, Contraints a Kontextuell Sense.

Merci fir d'Liesen! Wann Dir dësen Artikel genoss hutt, klappt w.e.g. fir datt anerer et och kënne liesen :)