| Model-View-Controller | |
|---|---|
| engelsk Model-View-Controller | |
| Struktur |
|
| Beskrevet i Design Patterns | Ikke |
Model-View-Controller ( MVC , "Model-View-Controller", "Model-View-Controller") er et skema til at adskille applikationsdata og kontrollogik i tre separate komponenter: model, view og controller - således at modifikationen af hver komponent kan udføres uafhængigt [1] .
Begrebet MVC blev beskrevet af Trygve Reenskaug i 1978 [1] [2] , som arbejdede på Xerox PARC forskningscenter om programmeringssproget Smalltalk . Senere implementerede Steve Burbeck mønsteret i Smalltalk-80 [1] [3] [4] .
Den endelige version af MVC-konceptet blev først offentliggjort i 1988 i tidsskriftet Technology Object [5] .
Efterfølgende begyndte designmønstret at udvikle sig. For eksempel blev en hierarkisk version af HMVC introduceret ; MVA , MVVM [6] [3] [4] .
En yderligere runde af popularitet blev skabt af udviklingen af hurtige implementeringsrammer i Python , PHP og Ruby : henholdsvis Django , Laravel og Ruby on Rails . På tidspunktet for 2017 har rammer med MVC indtaget en fremtrædende position i forhold til andre rammer uden dette mønster [7] .
Med udviklingen af objektorienteret programmering og konceptet med designmønstre blev der skabt en række modifikationer af MVC-konceptet, som, når de implementeres af forskellige forfattere, kan afvige fra originalen. Så for eksempel beskrev Erian Vermi i 2004 et eksempel på en generaliseret MVC [8] .
I forordet til Richard Pawsons afhandling " Nøgne genstande " nævner Trygve Reenskaug sin upublicerede tidligste version af MVC, ifølge hvilken [9] :
Hovedformålet med at anvende dette koncept er at adskille forretningslogikken ( model ) fra dens visualisering ( view , view ). På grund af denne adskillelse øges muligheden for genbrug af kode . Dette koncept er mest anvendeligt, når brugeren skal se de samme data på samme tid i forskellige sammenhænge og/eller fra forskellige synsvinkler. Især udføres følgende opgaver:
MVC-konceptet giver dig mulighed for at adskille modellen, visningen og controlleren i tre separate komponenter:
Modellen giver data og metoder til at arbejde med dem: forespørgsler til databasen, kontrol af korrekthed. Modellen er uafhængig af visningen (ved ikke, hvordan man renderer dataene) og controlleren (har ingen brugerinteraktionspunkter), og giver blot adgang til og manipulation af dataene.
Modellen er bygget på en sådan måde, at den reagerer på anmodninger ved at ændre dens tilstand, og meddelelsen til " observatører " kan indbygges .
Modellen kan på grund af uafhængighed af den visuelle repræsentation have flere forskellige repræsentationer for én "model"
Visningen er ansvarlig for at hente de nødvendige data fra modellen og sende dem til brugeren. Visningen behandler ikke brugerinput [10] .
Regulatoren sørger for "kommunikationen" mellem brugeren og systemet. Styrer og dirigerer data fra brugeren til systemet og omvendt. Bruger en model og en visning til at implementere den ønskede handling.
Da MVC ikke har en streng implementering, kan den implementeres på forskellige måder. Der er ingen generelt accepteret definition af, hvor forretningslogikken skal være placeret. Det kan både være i controlleren og modellen. I sidstnævnte tilfælde vil modellen indeholde alle forretningsobjekter med alle data og funktioner.
Nogle rammer definerer stift, hvor forretningslogikken skal placeres, andre har ikke sådanne regler.
Det er heller ikke specificeret, hvor valideringen af brugerindtastede data skal placeres. Simple valideringer kan endda forekomme i en visning, men de er mere almindelige i en controller eller model.
Internationaliseringen og formateringen af data mangler også en klar vejledning om placering.
For at implementere "Model-View-Controller" -skemaet bruges et ret stort antal designmønstre (afhængigt af kompleksiteten af den arkitektoniske løsning), hvoraf de vigtigste er " observer ", " strategi ", " linker " [11 ] .
Den mest typiske implementering er, hvor visningen adskilles fra modellen ved at etablere en interaktionsprotokol mellem dem, der anvender "begivenhedsapparatet" (betegnelse ved "begivenheder" af visse situationer, der opstår under afviklingen af programmet, og sende meddelelser vedr. dem til alle dem, der abonnerer på at modtage): For hver specifik ændring af de interne data i modellen (betegnet som en "begivenhed"), giver den besked til de synspunkter, der er afhængige af den, som abonnerer på at modtage en sådan notifikation - og visningen er opdateret. Sådan bruges " observatør " -mønsteret .
Når brugerens reaktion behandles, vælger visningen, afhængigt af reaktionen, den ønskede controller , som vil give en eller anden forbindelse med modellen. Til dette bruges " strategi "-mønsteret, eller der kan være en ændring ved at bruge " kommando " -mønsteret i stedet .
For muligheden for den samme type håndtering af underobjekter af en kompleks-sammensat hierarkisk type, kan " linker " -skabelonen bruges . Derudover kan andre designmønstre bruges - for eksempel " fabriksmetode ", som giver dig mulighed for at indstille standardcontrollertypen for den tilsvarende visning.
Begyndende programmører fortolker meget ofte MVC-arkitektoniske model som en passiv MVC-model: Modellen fungerer udelukkende som et sæt funktioner til at få adgang til data, og controlleren indeholder forretningslogik . Som et resultat er modelkoden faktisk et middel til at hente data fra DBMS , og controlleren er et typisk modul fyldt med forretningslogik. Som et resultat af denne forståelse begyndte MVC-udviklere at skrive kode, som Padrigue Brady (kendt i Zend Framework -fællesskabskredsene ) beskrev som "TTUK" ("Fat Stupid Ugly Controllers"; Fat Stupid Ugly Controllers):
Den gennemsnitlige TTUK hentede data fra en database (ved at bruge et databaseabstraktionslag, lod som om det var en model) eller manipulerede, validerede, skrev og videregav dataene til en visning. Denne tilgang er blevet meget populær, fordi brugen af sådanne controllere ligner den klassiske praksis med at bruge en separat php-fil for hver side af applikationen.
— [ http://blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstood-and-unappreciated/ The M in MVC: Why Models are Misunderstood and UnappreciatedMen i objektorienteret programmering bruges den aktive model [12] MVC, hvor modellen ikke kun er en kombination af dataadgangskode og DBMS , men også hele forretningslogikken ; modeller kan også indkapsle andre modeller i sig selv. Controllere, som elementer i et informationssystem , er kun ansvarlige for:
Kun i dette tilfælde bliver controlleren "tynd" og udfører udelukkende funktionen som et link (limlag) mellem de enkelte komponenter i informationssystemet .