Moderne applikasjoner trenger så mange funksjoner at prosessen med å utvikle dem har vokst i størrelse og kompleksitet. For å hjelpe, kan du bruke et arkitektonisk designmønster. De støtter byggingen av applikasjoner som er enkle å teste og vedlikeholde.

De tre mest populære designmønstrene er MVC, MVP og MVVM. MVC står for modell, visning og kontroller, mens MVP står for modell, visning og presentator, og MVVM for modell, visning og visningsmodell.

Arkitektoniske og designmønstre

Arkitektonisk mønster

Et arkitektonisk mønster tydeliggjør og definerer noen avgjørende komponenter i en programvarearkitektur. Selv om et arkitektonisk mønster formidler et bilde av et system, det er ikke en arkitektur. Faktisk er det en generell og gjenbrukbar løsning på et ofte forekommende problem i programvarearkitektur i en bestemt kontekst.

Design mønster

Et designmønster er en formalisert beste praksis som du kan bruke til å løse vanlige problemer når du designer en applikasjon eller et system.

Forskjellen mellom arkitektonisk og designmønster

instagram viewer

La oss starte med det vanlige begrepet – mønster. I programvare er et mønster en tilbakevendende egenskap som lar deg bryte ned en enorm og kompleks struktur til mindre, enklere komponenter. Du kan bruke dette mønsteret til å lage en generell løsning for en klasse med problemer.

På hvert nivå av programvareutvikling vil du bruke forskjellige verktøy. På mindre nivåer er disse verktøyene designmønstre. Arkitektoniske mønstre eksisterer på større nivåer, og programmeringsparadigmer på gjennomføringsnivå.

Hvorfor trenger vi arkitektoniske designmønstre?

Under programvareutvikling kan du bruke arkitektoniske designmønstre for å løse vanlige problemer. God arkitektur kan også hjelpe deg med å:

  • Del opp komplekse oppgaver i enklere oppgaver.
  • Reduser feil.
  • Produser testbar og vedlikeholdbar kode.

Men uten et arkitektonisk mønster kan du få problemer med å opprettholde appens forretningslogikk.

Modell, View, ViewModel, Controller og Presenter

Før du ser på hvert mønster, her er begrepene som utgjør dem:

  • Modell lagrer data og kommuniserer direkte med databasen. Modellen er den delen som representerer dine data og applikasjonslogikk. Den definerer forretningsreglene som administrerer datahåndtering, endring eller behandling.
  • Utsikt viser modellens data og er ansvarlig for dataenes representasjon i brukergrensesnittet.
  • ViewModel er eksklusivt for MVVM-mønster. Dette er en abstraksjon av visningslaget og fungerer også som en innpakning for modelldataene.
  • Kontroller er komponenten som integrerer utsikten og modellen.
  • Konferansier er en komponent som kun finnes i MVP-modellen. Presenter får input fra view-komponenten og behandler dataene ved hjelp av modellen.

MVC-, MVP- og MVVM-mønstre

Model-View-Controller-mønster

De MVC arkitektonisk mønster var den første, og den er populær i dag innen webapplikasjoner. Den ble introdusert på 1970-tallet. Dette mønsteret lar deg bygge en applikasjon rundt Separation of Concerns (SoC). Det letter innsatsen du trenger for å teste, vedlikeholde og utvikle applikasjonen din.

I MVC-mønsteret har modellen ingen forståelse av utsikten eller kontrolleren. Modellens observatør vil motta et varsel hver gang det er en endring i visningen og kontrolleren. Kontrolleren hjelper rutingprosessen med å koble modellen til den aktuelle visningen.

Noen av MVC-mønsterets fordeler er:

  • Separasjon av bekymringer (mer fokusert).
  • Gjør det enklere å teste og administrere koden.
  • Fremmer frakobling av applikasjonens lag.
  • Bedre kodeorganisering og gjenbrukbarhet.

Slik fungerer MVC:

På grunn av SoC kan MVC redusere kodestørrelsen og lage en god kode som er ren og håndterbar.

Model-View-Presenter-mønster

MVP-mønsteret deler to komponenter med MVC: modell og visning. Den erstatter kontrolleren med presentatøren. Presentatøren – som navnet tilsier – brukes til å presentere noe. Det lar deg gjøre narr av utsikten lettere.

I MVP har presentatøren funksjonaliteten til "mellommannen" fordi all presentasjonslogikk blir presset til den. Visningen og presentatøren i MVP er også uavhengige av hverandre og samhandler via et grensesnitt.

Her er en illustrasjon av hvordan MVP-mønsteret fungerer:

Programlederen mottar innspill fra brukeren via visningen. Den behandler deretter brukerens handlinger ved hjelp av modellen, og sender resultatene tilbake til visningen. Programlederen kommuniserer med utsikten gjennom grensesnitt.

Model-View-ViewModel Pattern

MVVM er den moderne utviklingen av MVC. Hovedmålet med MVVM er å gi et klart skille mellom domenelogikken og presentasjonslaget. MVVM støtter toveis databinding mellom visningen og visningsmodellen.

MVVM-mønsteret lar deg skille kodens visning og modell. Dette betyr at når modellen endres, trenger ikke visningen det, og omvendt. Ved å bruke en visningsmodell kan du utføre enhetstesting og teste din logiske oppførsel uten å involvere visningen din.

Her er en illustrasjon av hvordan MVVM fungerer:

Når du skal bruke MVC, MVP og MVVM

Nå som du har lært om hvert mønster, finn ut når du skal bruke dem.

Når du skal bruke MVC

MVC er ganske enkelt en implementering av Separation of Concerns. Hvis applikasjonen din trenger å skille dataene (modellen), dataknusingen (kontrolleren) og datapresentasjonen (visningen), vil MVC fungere bra. MVC fungerer også godt i en applikasjon der datakilden og/eller datapresentasjonen kan endres når som helst.

Når du skal bruke MVP

Du kan bruke MVP når applikasjonen din har en toveis flyt. Hvis brukerinteraksjoner trenger å be om noe fra modellen, og resultatet av denne forespørselen vil endre brukergrensesnittet umiddelbart, bør du vurdere MVP.

Når skal du bruke MVVM

Du vil bruke MVVM når:

  • Du må dele et prosjekt med en designer og design- og utviklingsarbeidet kan skje uavhengig.
  • Du trenger enhetstesting for løsningene dine.
  • Du må ha gjenbrukbare komponenter, både innenfor og på tvers av prosjekter i organisasjonen din.
  • Du vil ha mer fleksibilitet til å endre synspunktene dine uten å måtte refaktorere annen logikk i kodebasen.

Hvilket mønster bør du velge?

Hovedgrunnen til å bruke et designmønster er å redusere kompleksiteten. Du kan gjøre dette ved å redusere den generelle kompleksiteten eller ved å erstatte ukjent kompleksitet med den kjente. Hvis et designmønster ikke kan redusere kompleksiteten på noen av disse to måtene, ikke bruk noe av det; det vil ikke tilføre noen verdi overhodet.

Hvis du virkelig er sikker på at du bør bruke et designmønster, prøv å lage en sjekkliste. Baser det på situasjonene du har sett her og velg den som passer best for prosjektet ditt.