MVC, MVP, MVVM: Hvilken skal man vælge?

MVC, MVP, MVVM: Hvilken skal man vælge?

Moderne applikationer har brug for så mange funktioner, at processen med at udvikle dem er vokset i størrelse og kompleksitet. For at hjælpe kan du bruge et arkitektonisk designmønster. De understøtter opbygningen af ​​applikationer, der er nemme at teste og vedligeholde.





De tre mest populære designmønstre er MVC, MVP og MVVM. MVC står for model, view og controller, mens MVP står for model, view og presenter, og MVVM står for model, view og view model.





Arkitektoniske og designmæssige mønstre

Arkitektonisk mønster

Et arkitektonisk mønster tydeliggør og definerer nogle afgørende komponenter i en softwarearkitektur. Selvom et arkitektonisk mønster formidler et billede af et system, det er ikke en arkitektur . Faktisk er det en generel og genbrugelig løsning på et almindeligt forekommende problem i softwarearkitektur i en bestemt sammenhæng.





Design mønster

Et designmønster er en formaliseret best practice, som du kan bruge til at løse almindelige problemer, når du designer en applikation eller et system.

Forskellen mellem arkitektonisk og designmønster

Lad os starte med det almindelige udtryk - mønster. I software er et mønster en tilbagevendende egenskab, der lader dig nedbryde en enorm og kompleks struktur i mindre, enklere komponenter. Du kan bruge dette mønster til at lave en generel løsning til en klasse af problemer.



På hvert niveau af softwareudvikling vil du bruge forskellige værktøjer. På mindre niveauer er disse værktøjer designmønstre. Arkitektoniske mønstre findes på større niveauer, og programmeringsparadigmer på implementeringsniveau.

Hvorfor har vi brug for arkitektoniske designmønstre?

Under softwareudvikling kan du bruge arkitektoniske designmønstre til at løse almindelige problemer. God arkitektur kan også hjælpe dig med at:





  • Opdel komplekse opgaver i enklere opgaver.
  • Reducer fejl.
  • Fremstil testbar og vedligeholdelig kode.

Men uden et arkitektonisk mønster kan du få problemer med at opretholde din apps forretningslogik.

Model, View, ViewModel, Controller og Presenter

Før du ser på hvert mønster, er her de udtryk, der udgør dem:





  • Model gemmer data og kommunikerer direkte med databasen. Model er den del, der repræsenterer dine data og applikationslogik. Den definerer de forretningsregler, der styrer datahåndtering, ændring eller behandling.
  • Udsigt viser modellens data og er ansvarlig for dataenes repræsentation i brugergrænsefladen.
  • ViewModel er eksklusivt til MVVM-mønster. Dette er en abstraktion af visningslaget og fungerer også som en indpakning for modeldataene.
  • Controller er den komponent, der integrerer udsigten og modellen.
  • Oplægsholder er en komponent, der kun findes i MVP-modellen. Oplægsholder får input fra view-komponenten og behandler dataene ved hjælp af modellen.

MVC-, MVP- og MVVM-mønstre

Model-View-Controller-mønster

Det MVC arkitektonisk mønster var den første, og den er populær i dag inden for webapplikationer. Det blev introduceret i 1970'erne. Dette mønster lader dig bygge en applikation omkring Separation of Concerns (SoC). Det letter den indsats, du skal bruge for at teste, vedligeholde og udvikle din applikation.

I MVC-mønsteret har modellen ingen forståelse af udsigten eller controlleren. Modellens observatør vil modtage en advarsel, når der er en ændring i visningen og controlleren. Controlleren hjælper routingprocessen med at forbinde modellen til den relevante visning.

Nogle af MVC-mønstrets fordele er:

  • Adskillelse af bekymringer (mere fokuseret).
  • Gør det nemmere at teste og administrere koden.
  • Fremmer afkobling af applikationens lag.
  • Bedre kodeorganisering og genbrugelighed.

Sådan fungerer MVC:

  Billede af et diagram, der illustrerer, hvordan MVC fungerer

På grund af SoC'en kan MVC reducere kodestørrelsen og lave en god kode, der er ren og overskuelig.

Model-View-Presenter-mønster

MVP-mønsteret deler to komponenter med MVC: model og visning. Den erstatter controlleren med præsentationsværten. Præsentatoren - som navnet antyder - bruges til at præsentere noget. Det giver dig mulighed for lettere at håne udsigten.

I MVP har præsentationsværten funktionaliteten som 'mellemmanden', fordi al præsentationslogik er skubbet til den. Visningen og oplægsholderen i MVP er også uafhængige af hinanden og interagerer via en grænseflade.

hvordan man downloader beskyttede videoer fra ethvert websted

Her er en illustration af, hvordan MVP-mønsteret fungerer:

  Billede af et diagram, der illustrerer, hvordan MVP fungerer

Oplægsholderen modtager input fra brugeren via visningen. Den behandler derefter brugerens handlinger ved hjælp af modellen og sender resultaterne tilbage til visningen. Oplægsholderen kommunikerer med udsigten gennem grænseflader.

Model-View-ViewModel mønster

MVVM er den moderne udvikling af MVC. Hovedmålet med MVVM er at give en klar adskillelse mellem domænelogikken og præsentationslaget. MVVM understøtter tovejs databinding mellem visningen og visningsmodellen.

MVVM-mønsteret giver dig mulighed for at adskille din kodes visning og model. Det betyder, at når modellen ændrer sig, behøver visningen ikke det, og omvendt. Ved at bruge en viewmodel kan du lave enhedstest og teste din logiske adfærd uden at involvere dit syn.

Her er en illustration af, hvordan MVVM virker:

  Billede af et diagram, der illustrerer, hvordan MVVM fungerer

Hvornår skal du bruge MVC, MVP og MVVM

Nu hvor du har lært om hvert mønster, skal du finde ud af, hvornår du skal bruge dem.

Hvornår skal du bruge MVC

MVC er simpelthen en implementering af Separation of Concerns. Hvis din applikation skal adskille data (model), dataknas (controller) og datapræsentation (visning), vil MVC fungere godt. MVC fungerer også godt i en applikation, hvor datakilden og/eller datapræsentationen kan ændres til enhver tid.

Hvornår skal du bruge MVP

Du kan bruge MVP, når din applikation har et tovejsflow. Hvis brugerinteraktioner skal anmode om noget fra modellen, og resultatet af denne anmodning vil ændre brugergrænsefladen med det samme, skal du overveje MVP.

Hvornår skal man bruge MVVM

Du ønsker at bruge MVVM, når:

  • Du skal dele et projekt med en designer, og design- og udviklingsarbejdet kan foregå selvstændigt.
  • Du har brug for enhedstest til dine løsninger.
  • Du skal have genanvendelige komponenter, både inden for og på tværs af projekter i din organisation.
  • Du ønsker mere fleksibilitet til at ændre dine synspunkter uden at skulle refaktorere anden logik i kodebasen.

Hvilket mønster skal du vælge?

Hovedårsagen til at bruge et designmønster er at reducere kompleksiteten. Du kan gøre dette ved at reducere den overordnede kompleksitet eller ved at erstatte ukendt kompleksitet med det velkendte. Hvis et designmønster ikke kan reducere kompleksiteten på en af ​​disse to måder, skal du ikke bruge noget af det; det vil ikke tilføje nogen som helst værdi.

Hvis du virkelig er sikker på, at du skal bruge et designmønster, så prøv at lave en tjekliste. Baser det på de situationer, du har set her, og vælg den, der passer bedst til dit projekt.