Articles

Hva er VIPER?

Dette er det første innlegget i en serie innlegg om iOS-prosjektarkitektur. I disse innleggene har jeg ikke tenkt å gå inn i detaljer om arkitektoniske mønstre fordeler og ulemper, i stedet vil fokuset være på å skissere forskjellige arkitektoniske strukturer, som kan brukes i et iOS-prosjekt. Jeg har imidlertid tenkt å skrive en mer sta stykke som en oppsummering / konklusjon for de ulike begrepene introdusert gjennom denne serien senere.

I dette innlegget vil jeg introdusere VIPER architectural pattern. VIPER kan brukes som et designmønster på en rekke plattformer, i dette innlegget vil jeg fokusere på å bruke VIPER i et iOS-prosjekt.

VIPER står for de ulike komponentene i det arkitektoniske mønsteret; View, Interactor, Presenter, Entity og Routing. Kjerneprinsippet til VIPER er å skille appens funksjonalitet i disse forskjellige komponentene, for å oppnå lav kobling mellom appens ulike komponenter og å følge prinsippet om enkeltansvar.Bortsett fra komponentene som er inkludert I VIPER som er nevnt ovenfor, BRUKER VIPER-mønsteret også hjelpere, som styrer logikken mellom eksterne kilder, for eksempel en database og iOS-applikasjonen, kan disse komponentene refereres til Som Nettverksadministratorer.

VIPER forskjellige komponenter

for å starte, vil jeg gå gjennom de ulike komponentene I VIPER og deres ansvar. Mens jeg beskriver VIPER ‘ s forskjellige komponenter, vil jeg gi eksempler på hvor du finner de forskjellige komponentene i et tradisjonelt satt OPP mvc iOS-prosjekt (der det er aktuelt).

når komponentene er innført, vil jeg fokusere på hvordan de ulike komponentene kommer sammen i et prosjekt og hvordan komponentene forholder seg til hverandre.

Vis

visningen er ansvarlig for å vise informasjon til brukeren av appen. Siden visningen er hva brukeren ser, er dette en viktig komponent som gir brukeren et direkte grensesnitt til applikasjonen – i et tradisjonelt iOS-prosjekt kan dette være en visning i et storyboard eller i en .xib-fil. Visningen er derfor også ansvarlig for å gi appen en måte for en bruker å legge inn informasjon.

Interactor

interactor inneholder appens forretningslogikk om hvordan man håndterer data. Interactor er ikke direkte ansvarlig for å hente data fra en server, dette er ofte allokert til en Eller Flere Nettverksadministratorer. Interactor er imidlertid ansvarlig for å samhandle med Disse Nettverksadministratorene. Siden en bestemt app kan kreve at data hentes fra flere, forskjellige datakilder, kan interactor initialisere nettverksforespørsler gjennom flere, forskjellige nettverksadministratorer. Det er opp til interactor å hente de nødvendige dataene for appens spesifikke brukstilfelle, fra de forskjellige datapunktene, i henhold til appens forretningslogikk. Når data er hentet fra alle eksterne servere via nettverksadministratorer, håndterer interactor enhver datamanipulasjon som kan være nødvendig.

Merk: Hvis du er kjent med en moderne mvvm-arkitektur, kan ansvaret for en interactor sammenlignes med ansvaret FOR Mvvms Visningsmodell.

Presentatør

presentatørens ansvar er å anvende logikken i hvordan innholdet skal vises. Presentatøren bruker dataene fra interactor og bruker deretter den nødvendige logikken om hvordan disse dataene skal presenteres i en visning. Presentatøren er også ansvarlig for logikken om hvordan søknaden skal svare på brukerinnganger og brukerinteraksjoner. Dette ansvaret er ofte gitt Til En ViewController i sammenheng med et iOS-prosjekt.

Enhet

en enhet er en datalagringsmodell. Dette kan enten være en vedvarende lagringsmodell – for Eksempel Et Kjernedataobjekt – eller det kan være en mer midlertidig lagringsmodell-for Eksempel En Struktur, Klasse eller En Enum. Enheten skal ikke inneholde noen logikk knyttet til formatering av data før den vises, og den skal heller ikke inneholde logikk om hvordan dataene skal hentes (f. eks. nettverksforespørsel). En enhet inneholder bare variabler som er spesifikke for modellen den representerer. Ansvaret for hvordan du viser dataene til en enhet er i stedet gitt til presentatøren, og en nettverksadministrator er ansvarlig for hvordan du henter data.

Routing

endelig er rutingskomponenten ansvarlig for logikken som kreves for, og navigasjonen mellom appens forskjellige visninger. Denne komponenten beskriver hva som kreves for å vise hver av appens visninger. Når alle avhengighetene som kreves for en bestemt visning er oppgitt/opprettet, initialiserer routing visningen, og gir disse avhengighetene (dette kalles avhengighetsinjeksjon) og presenterer deretter visningen.

Merk: rutingskomponenten tar ansvar for å navigere mellom ulike visninger, dette er et ansvar som tradisjonelt er delt mellom en storyboard segue og En viewcontroller (i en prepareForSegue-funksjon). En app som bruker VIPER-arkitekturen, inneholder derfor vanligvis ikke noen segues mellom et storyboards forskjellige synspunkter.

Bemerkelsesverdig

i Henhold til VIPER-arkitekturen bør ingen andre klasser enn en dataansvarlig ha noen bevissthet om Kjernedata eller Kjernedataobjekter. I stedet konverterer en datastyringsklasse Kjernedataobjektet til EN PONSO (Vanlig Gammel NSObject) før den sendes til en annen klasse, for eksempel en interaktorklasse.

Ved Hjelp Av Moduler med VIPER

en skjerm eller et sett med skjermer kan legges Til En Modul. En modul kan ganske enkelt være en mappe i prosjektet som inneholder funksjonaliteten som kreves for en bestemt skjerm. Modulmønsteret kan være nyttig for å erstatte eller gjenbruke spesifikk oppførsel for ulike plattformer. For eksempel, hvis en bestemt funksjonalitet bare eksisterer for en iPad-app, er den lett utskiftbar av en annen modul for en iPhone-applikasjon.

hvordan vil denne strukturen se ut i et iOS-prosjekt?

Så langt gjennom denne artikkelen har Jeg identifisert de forskjellige komponentene I VIPER, samt disse komponentenes forskjellige ansvarsområder. La oss gå gjennom hvordan disse komponentene samhandler med hverandre og hvordan de passer sammen i et prosjekt i mer detalj.

det faktum at hver av komponentene i VIPER-modellen er dedikert til en bestemt oppgave, gjør det enkelt for oss å kombinere komponentene for å oppfylle en oppgave som kreves for at appen skal fungere, samt gjenbruke komponentene i forskjellige deler av appen. Som diagrammet ovenfor viser, samhandler de forskjellige komponentene med hverandre for å nå et bestemt mål.

Mens Visningen gir en bruker en bestemt skjerm i appen, Spiller Presentatøren en viktig rolle i å håndtere beslutningstaking av hvordan data skal vises i en visning og hva de skal gjøre med data som en bruker går inn i en visning. Presentatøren henter data som skal vises i En bestemt visning Fra Interactor og formaterer dataene før de vises i visningen. Når brukeren av appen samhandler med visningen, er det presentatørens ansvar å bestemme hvordan visningen skal endres, for å gi brukeren nødvendig tilbakemelding.

hvis brukerinndataene skal lagres for senere henting, videresender presentatøren dataene til en interactor. Interactor bestemmer hvordan dataene skal formateres ved å bruke relevant forretningslogikk, før de enten overleveres til en nettverksleder (for ekstern lagring av informasjonen) eller Til En Enhet.

en app inneholder ofte flere skjermer, med ulike funksjoner, dedikert til å oppfylle en bestemt brukstilfelle. Hver av disse skjermene (eller et sett med relaterte skjermer) består hver Av En Visning, En Interaktor, En Presentatør, En Enhet og En Rutingskomponent, som kombinert kan refereres til som En Modul. Siden noen skjermer kan kreve de samme enhetene eller samme interactor som en annen skjerm, kan EN VIPER komponent gjenbrukes på tvers av ulike moduler.

Ruting kan eksistere på ulike nivåer i programmet. Det kan være en ruter som er spesifikk for en modul, og gir navigasjonen mellom en samling skjermer. En ruter kan også eksistere på høyere, mer overordnet appnivå, og gir navigasjonsfunksjonaliteten mellom appene høyere nivå, hovedvisninger (for eksempel opprettelse av visninger og ruting til disse visningene, fra en fanelinje).

Nyttige lenker:

  • Architecting iOS Apps med VIPER-by objc.io
  • iOS Arkitektur Mønstre – Av Bohdan Orlov
  • Bygge iOS App med VIPER Arkitektur – Av Amit Shekhar

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.