I løbet af de sidste par år har hjemmesider skiftet fra simple HTML-sider med en smule CSS til utroligt komplekse applikationer med tusindvis af udviklere, der arbejder på dem på samme tid. For at arbejde med disse komplekse webapplikationer bruger udviklere forskellige designmønstre til at udforme deres projekter, for at gøre koden mindre kompleks og lettere at arbejde med. Det mest populære af disse mønstre er MVC også kendt som Model View Controller.

Hvad er MVC?

Det Model-View-Controller (MVC) framework er et arkitektonisk/designmønster, der adskiller en applikation i tre logiske hovedkomponenter Model , Udsigt , og Controller . Hver arkitektonisk komponent er bygget til at håndtere specifikke udviklingsaspekter af en applikation. Det isolerer forretningslogikken og præsentationslaget fra hinanden. Det blev traditionelt brugt til desktop grafiske brugergrænseflader (GUI'er) . I dag er MVC en af ​​de mest brugte industristandard webudviklingsrammer til at skabe skalerbare og udvidelige projekter. Det bruges også til at designe mobilapps.

MVC blev skabt af Trygve Reenskaug . Hovedmålet med dette designmønster var at løse problemet med brugere, der kontrollerer et stort og komplekst datasæt ved at opdele en stor applikation i specifikke sektioner, der alle har deres eget formål.

Funktioner af MVC:

• Det giver en klar adskillelse af forretningslogik, UI-logik og inputlogik.
• Det giver fuld kontrol over dine HTML og URL'er, hvilket gør det nemt at designe webapplikationsarkitektur.
• Det er en kraftfuld URL-mapping-komponent, hvormed vi kan bygge applikationer, der har forståelige og søgbare URL'er.
• Det understøtter Testdrevet udvikling (TDD).

For at vide mere om fordelene ved at bruge MVC Framework henvises til artiklen – Fordele ved at bruge MVC framework

Komponenter af MVC:

MVC-rammen omfatter følgende 3 komponenter:

• Controller
• Model
• Udsigt

MVC Arkitektur Design

Controller:

Controlleren er den komponent, der muliggør sammenkoblingen mellem visningerne og modellen, så den fungerer som en mellemmand. Controlleren behøver ikke at bekymre sig om håndtering af datalogik, den fortæller blot modellen, hvad den skal gøre. Den behandler al forretningslogik og indgående anmodninger, manipulerer data ved hjælp af Model komponent og interagere med Udsigt for at gengive det endelige output.

kruskal algoritme

Udsigt:

Det Udsigt komponent bruges til al UI-logikken i applikationen. Det genererer en brugergrænseflade for brugeren. Visninger skabes af de data, som er indsamlet af modelkomponenten, men disse data tages ikke direkte, men gennem controlleren. Den interagerer kun med controlleren.

Model:

Det Model komponent svarer til al den data-relaterede logik, som brugeren arbejder med. Dette kan repræsentere enten de data, der overføres mellem View- og Controller-komponenterne eller andre forretningslogik-relaterede data. Det kan tilføje eller hente data fra databasen. Den reagerer på controllerens anmodning, fordi controlleren ikke kan interagere med databasen af ​​sig selv. Modellen interagerer med databasen og giver de nødvendige data tilbage til controlleren.

Arbejde med MVC-rammen med et eksempel:

Lad os forestille os, at en slutbruger sender en anmodning til en server for at få en liste over elever, der studerer i en klasse. Serveren ville derefter sende denne anmodning til den pågældende controller, der håndterer elever. Denne controller ville derefter anmode modellen, der håndterer eleverne, om at returnere en liste over alle elever, der studerer i en klasse.

Strømmen af ​​data i MVC-komponenter

Modellen vil forespørge databasen om listen over alle elever og derefter returnere listen tilbage til controlleren. Hvis svaret tilbage fra modellen var vellykket, ville controlleren bede den visning, der er knyttet til eleverne, om at returnere en præsentation af listen over elever. Denne visning ville tage listen over elever fra controlleren og gengive listen til HTML, som kan bruges af browseren.

Controlleren ville derefter tage denne præsentation og returnere den tilbage til brugeren. Dermed afsluttes anmodningen. Hvis modellen tidligere returnerede en fejl, ville controlleren håndtere denne fejl ved at bede visningen, der håndterer fejl, om at gengive en præsentation for den pågældende fejl. Denne fejlpræsentation ville så blive returneret til brugeren i stedet for elevlistepræsentationen.

Som vi kan se fra ovenstående eksempel, håndterer modellen alle data. Visningen håndterer alle præsentationerne, og controlleren fortæller bare modellen og visningen af, hvad den skal gøre. Dette er den grundlæggende arkitektur og funktion af MVC-rammen.

MVC arkitektoniske mønster giver os mulighed for at overholde følgende designprincipper:
1. Del og hersk. De tre komponenter kan designes lidt uafhængigt af hinanden.
2. Øge sammenhængskraften. Komponenterne har stærkere lagsammenhæng, end hvis visningen og controlleren var sammen i et enkelt UI-lag.
3. Reducer koblingen. Kommunikationskanalerne mellem de tre komponenter er minimale og nemme at finde.
4. Øg genbrug. Visningen og controlleren gør normalt udstrakt brug af genanvendelige komponenter til forskellige former for UI-kontroller. Brugergrænsefladen vil dog blive applikationsspecifik, derfor vil den ikke være let genbrugelig.
5. Design for fleksibilitet. Det er normalt ret nemt at ændre brugergrænsefladen ved at ændre visningen, controlleren eller begge dele.

Fordele ved MVC:

• Koderne er nemme at vedligeholde, og de kan nemt udvides.
• MVC'en model komponent kan testes separat.
• Komponenterne i MVC kan udvikles samtidigt.
• Det reducerer kompleksiteten ved at opdele en applikation i tre enheder. Model, visning og controller.
• Det understøtter Testdrevet udvikling (TDD).
• Det fungerer godt for webapps, der understøttes af store teams af webdesignere og udviklere.
• Denne arkitektur hjælper med at teste komponenter uafhængigt, da alle klasser og objekter er uafhængige af hinanden
• Søgemaskineoptimering (SEO) Venlige.

Ulemper ved MVC:

• Det er svært at læse, ændre, teste og genbruge denne model
• Det er ikke egnet til at bygge små applikationer.
• Ineffektiviteten af ​​dataadgang i udsigt.
• Frameworknavigationen kan være kompleks, da den introducerer nye lag af abstraktion, som kræver, at brugerne tilpasser sig dekomponeringskriterierne for MVC.
• Øget kompleksitet og ineffektivitet af data

Populære MVC-rammer:

Nogle af de mest populære og meget brugte MVC-rammer er anført nedenfor.

streng til json-objekt

• Ruby on Rails
• Django
• CherryPy
• Fjeder MVC
• Katalysator
• Skinner
• Zend Framework
• Brændstof PHP
• Laravel
• Symfoni

MVC bruges generelt på applikationer, der kører på en enkelt grafisk arbejdsstation. Opdelingen af ​​logiske komponenter muliggør læsbarhed og modularitet samt gør det mere behageligt for testdelen.