| Model-View-Controller | |
|---|---|
| engelsk Model-View-Controller | |
| Strukturera |
|
| Beskrivs i Design Patterns | Inte |
Model-View-Controller ( MVC , "Model-View-Controller", "Model-View-Controller") är ett schema för att separera applikationsdata och styrlogik i tre separata komponenter: modell, vy och styrenhet - så att modifieringen av varje komponent kan utföras oberoende [1] .
Begreppet MVC beskrevs av Trygve Reenskaug 1978 [1] [2] , som arbetade på Xerox PARC forskningscenter om programmeringsspråket Smalltalk . Senare implementerade Steve Burbeck mönstret i Smalltalk-80 [1] [3] [4] .
Den slutliga versionen av MVC-konceptet publicerades först 1988 i tidskriften Technology Object [5] .
Därefter började designmönstret utvecklas. Till exempel introducerades en hierarkisk version av HMVC ; MVA , MVVM [6] [3] [4] .
Ytterligare en omgång av popularitet skapades av utvecklingen av ramverk för snabb distribution i Python , PHP och Ruby : Django , Laravel respektive Ruby on Rails . Ramverk med MVC har vid tidpunkten 2017 tagit en framträdande position i förhållande till andra ramverk utan detta mönster [7] .
Med utvecklingen av objektorienterad programmering och konceptet designmönster skapades ett antal modifieringar av MVC-konceptet, som, när de implementeras av olika författare, kan skilja sig från originalet. Så till exempel beskrev Erian Vermi 2004 ett exempel på en generaliserad MVC [8] .
I förordet till Richard Pawsons avhandling " Naked objects " nämner Trygve Reenskaug sin opublicerade tidigaste version av MVC, enligt vilken [9] :
Huvudsyftet med att tillämpa detta koncept är att separera affärslogiken ( modellen ) från dess visualisering ( vy , vy ). På grund av denna separation ökar möjligheten för kodåteranvändning . Detta koncept är mest användbart när användaren behöver se samma data samtidigt i olika sammanhang och/eller från olika synvinklar. I synnerhet utförs följande uppgifter:
MVC-konceptet låter dig dela upp modellen, vyn och styrenheten i tre separata komponenter:
Modellen tillhandahåller data och metoder för att arbeta med dem: frågor till databasen, kontroll av korrekthet. Modellen är oberoende av vyn (vet inte hur man renderar data) och controllern (har inga användarinteraktionspunkter), bara ger åtkomst till och manipulering av data.
Modellen är byggd på ett sådant sätt att den svarar på förfrågningar genom att ändra dess tillstånd, och meddelandet från " observatörer " kan byggas in.
Modellen kan, på grund av oberoende av den visuella representationen, ha flera olika representationer för en "modell"
Vyn ansvarar för att hämta nödvändig data från modellen och skicka den till användaren. Vyn behandlar inte användarinmatning [10] .
Styrenheten tillhandahåller "kommunikationen" mellan användaren och systemet. Styr och dirigerar data från användaren till systemet och vice versa. Använder en modell och en vy för att genomföra önskad åtgärd.
Eftersom MVC inte har en strikt implementering kan den implementeras på olika sätt. Det finns ingen allmänt accepterad definition av var affärslogiken ska placeras. Det kan finnas i både styrenheten och modellen. I det senare fallet kommer modellen att innehålla alla affärsobjekt med alla data och funktioner.
Vissa ramverk definierar strikt var affärslogiken ska placeras, andra har inte sådana regler.
Det anges inte heller var valideringen av användarinmatade data ska placeras. Enkla valideringar kan till och med förekomma i en vy, men de är vanligare i en styrenhet eller modell.
Internationaliseringen och formateringen av data saknar också tydlig vägledning om plats.
För att implementera "Model-View-Controller" -schemat används ett ganska stort antal designmönster (beroende på komplexiteten i den arkitektoniska lösningen), varav de viktigaste är " observer ", " strategi ", " linker " [11 ] .
Den mest typiska implementeringen är där vyn separeras från modellen genom att upprätta ett interaktionsprotokoll mellan dem som använder "händelseapparaten" (beteckning med "händelser" av vissa situationer som uppstår under körningen av programmet, och skicka meddelanden om dem till alla som prenumererar på att ta emot) : För varje specifik ändring av den interna informationen i modellen (betecknad som en "händelse"), meddelar den de vyer som är beroende av den som prenumererar på att ta emot ett sådant meddelande - och vyn är uppdaterad. Så här används "observatörsmönstret " .
Vid bearbetning av användarens reaktion väljer vyn, beroende på reaktionen, den önskade styrenheten , som kommer att ge en eller annan anslutning till modellen. För detta används " strategi "-mönstret, eller så kan det bli en modifiering med " kommando " -mönstret istället .
För möjligheten till samma typ av hantering av delobjekt av en komplex sammansatt hierarkisk typ, kan mallen " linker " användas . Dessutom kan andra designmönster användas - till exempel " fabriksmetod ", som gör att du kan ställa in standardstyrenhetstypen för motsvarande vy.
Nybörjarprogrammerare tolkar mycket ofta MVC-arkitektoniska modellen som en passiv MVC-modell: modellen fungerar enbart som en uppsättning funktioner för åtkomst till data, och styrenheten innehåller affärslogik . Som ett resultat är modellkoden i själva verket ett sätt att hämta data från DBMS , och styrenheten är en typisk modul fylld med affärslogik. Som ett resultat av denna förståelse började MVC-utvecklare skriva kod som Padrigue Brady (känd i Zend Framework -gemenskapskretsarna ) beskrev som "TTUK" ("Fat Stupid Ugly Controllers"; Fat Stupid Ugly Controllers):
Den genomsnittliga TTUK hämtade data från en databas (med hjälp av ett databasabstraktionslager, låtsades att det var en modell) eller manipulerade, validerade, skrev och skickade data till en vy. Detta tillvägagångssätt har blivit mycket populärt eftersom användningen av sådana kontroller liknar den klassiska metoden att använda en separat php-fil för varje sida i programmet.
— [ http://blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstood-and-unappreciated/ The M i MVC: Why Models are Misunderstood and UnappreciatedMen i objektorienterad programmering används den aktiva modellen [12] MVC, där modellen inte bara är en kombination av dataåtkomstkod och DBMS , utan även hela affärslogiken ; modeller kan också kapsla in andra modeller i sig själva. Kontrollanter, som delar av ett informationssystem , är endast ansvariga för:
Endast i detta fall blir styrenheten "tunn" och utför enbart funktionen av en länk (limlager) mellan de enskilda komponenterna i informationssystemet .