Hvad er MVC, og hvordan er det som en sandwichbutik?

På dagens internet har websteder tendens til at være interaktive, dynamiske og tjene en slags funktion. De kan være mere end en statisk HTML- og CSS-side. Her er, hvor Model View Controller (MVC) arkitektonisk mønster kommer ind.

Brugerinteraktion muliggør brugssager, som kun ville være umulige med en statisk indlæst side. Derfor er det i moderne webudvikling vigtigt at forstå, hvordan dynamiske sider oprettes. Måske er nøglen til dette fortrolighed med MVC's arkitektoniske mønster.

Hvis du er nybegynder inden for webudvikling, kan ord som “arkitektonisk mønster” lyde skræmmende komplekse og abstrakte. Men den generelle idé bag MVC er faktisk meget intuitiv. Jeg vil gøre mit bedste for at forklare det på en sådan måde i denne artikel.

Er MVC vigtigt at forstå?

Efter min mening er svaret på dette spørgsmål ja.

MVC er vigtigt at forstå, fordi det er den grundlæggende struktur, som de fleste webapplikationer er bygget på. Det samme gælder også for mobilapps og desktop-programmer.

Der er mange variationer omkring den grundlæggende idé om MVC. Det oprindelige koncept blev oprettet omkring 1978 på Xerox PARC af Trygve Reenskaug. Det var beregnet til at hjælpe en slutbruger med at manipulere og kontrollere et underliggende computersystem på en mere visuel og intuitiv måde.

MVC opnår dette, dog ved at lade en bruger interagere med en brugergrænseflade. Dette giver mulighed for manipulation og kontrol over systemet.

Konceptet på højt niveau

Uden at bruge nogen smarte ord vil jeg nu forklare den grundlæggende idé bag MVC gennem en simpel brugssag.

Forestil dig, at du er i en sandwichbutik. Du går op til tælleren og ser på menuen.

Du beslutter, at du vil have kalkun sandwich (faktisk kan du allerede forestille dig at bide i det). Så du fortæller ekspeditøren din ordre.

Ekspeditøren ved præcis, hvad du vil have, når du bestiller kalkun sandwich. Han vender sig om til sandwichfremstillingsstationen og fortæller folkene der, hvad de har brug for at vide for at opfylde din ordre.

Sandwichfremstillingsholdet har mange ressourcer til rådighed. Skinke, kalkun, tun, salat og ost kan alle gå i sandwichene. De tager de nødvendige ingredienser til din ordre og samler dem i den kalkun sandwich, du har bestilt.

Når sandwichen er færdig, overleveres den til dig. Du har nu den kalkun sandwich, du ville have.

En forklaring

I dette foregående eksempel var der tre separate og forskellige objekter, som alle repræsenterer en del i vores MVC:

  • Sandwichfremstillingsstationen (model)
  • Den færdige sandwich, du modtog til sidst (Vis)
  • Kontorist (controller)

Da du bestilte din sandwich, havde du en tydelig idé om, hvad du forventede at slutresultatet skulle være: en kalkun sandwich ( se ).

Dette er det samme som når du er på et websted. For eksempel kan du på Facebook trykke på knappen 'Venner' for at se en liste over dine venner. Du forventer, at din venneliste vises, og du kan allerede visualisere den i dit sind.

Når du trykker på knappen 'Venner', fremsætter du en anmodning til Facebooks servere. Anmodningen er at betjene dig med din venneliste, ligesom du bad om din sandwich til ekspeditøren ( controller ).

Din anmodning ankommer til Facebooks servere. Det rammer deres controller, som forsøger at løse det. Det griber derefter alle dine venner fra en database, ligesom sandwich-maker ( model ) griber alle ingredienserne.

Disse ressourcer (dine vennelistedata) samles til et svar. Dette svarer til, hvordan sandwichproducenten samlede alle ingredienserne til en færdig sandwich ( visning ).

Denne venneliste sendes derefter til dig til forbrug, ligesom sandwichen var i slutningen af ​​din ordre.

Resumé

Ekspeditøren er den registeransvarlige:

  • Han kender alle de mulige kombinationer af sandwich, du kan bestille
  • Han samler dine oplysninger og sender en ordre tilbage for at blive løst

Sandwichproducenterne er modellerne:

  • De ved, hvilke ting der er nødvendige for at samle din færdige sandwich

Sandwichen er udsigten:

  • Det er den 'ting' slutbrugeren endelig får

Brug af en webramme

Styring:

Controlleren håndterer indgående anmodninger. I en webramme ville dette være en erklæring om specifikke URL'er, der kortlægges til specifik funktionalitet, der sammensætter din anmodning.

Example URLswebsite.com/profile/ --> returns your profilewebsite.com/friends/ --> returns list of friendswebsite.com/friend={userName}/ --> returns specific friend

Model:

Sådan ser dine data ud på bagsiden.

User:- userName- firstName- lastName- friends

Udsigt:

Dette er HTML-skabelonen, der returneres, efter din anmodning er løst. Hvis anmodningen er vellykket, skal du få en side med dine venner. Ellers får du muligvis en 404 'Ikke fundet' side.


    
  • Friend 1: {friendList[0].userName}
  • Friend 2: {friendList[1].userName}
  • Friend 3: {friendList[2].userName}
  • ...

Konklusion

Når de vekselvirker med et system, du er normalt i stand til C reate, R etreive, U pdatér og D DELETE objekter i den underliggende database. Dette forkortes ofte til " CRUD ." Her har vi set på at hente data.

Jeg forklarede ikke her, hvordan en bruger kan ændre dataene i databasen ( C , U og D i CRUD ). Normalt er du i stand til at tilføje, opdatere og slette ting på et websted.

Funktionaliteten til dette er stort set den samme som forklaret ovenfor. Forskellen er, at dine data er knyttet til din anmodning til controlleren.

Jeg håber, at du nu har en klarere forståelse af, hvad MVC-arkitektur er, og hvordan det kan fungere.

Hvis du syntes, denne forklaring var nyttig, eller hvis du har spørgsmål eller tænkte på, hvordan du kan forbedre denne artikel, er du velkommen til at kommentere!