Vorige Volgende

MVC is een afkorting voor Model View Controller. Het model is in 1979 ontwikkeld door Trygve Reenskaug, een Noorse computerwetenschapper. Hij werkte toen bij het legendarische onderzoekscentrum Xerox Parc in de USA, aan de programmeertaal Smalltalk. Bedenk dat er toen geen personal computers bestonden. Het duurde tot 1994 voordat het wereldwijd aandacht kreeg. Dat kwam doordat het werd beschreven in het boek

Design Patterns: Elements of Reusable Object-Oriented Software

. Een standaardwerk voor programmeurs.

Uit dit boek:

MVC consists of three kinds of objects. THe Model is the application object, the View is its screen presentation, and the Controller defines the way the user interface reacts to user input.

De eerste naam was trouwens MVCE, waarin de E voor Editor stond. Met de Editor zou dan data in de database aangepast kunnen worden. Redelijk onnodig.

Het MVC model deelt de verantwoordelijkheden in een computerprogramma op in drie onderdelen. Het Model gaat over alle gegevens (data). Dat is het opslaan ervan, het lezen van de data, controleren op fouten etc.

De View zit helemaal aan de andere kant. Deze toont gegevens en vraagt invoer van de gebruiker. De View krijgt de data om te tonen aangereikt. De View kan en zal dan ook nooit toegang hebben tot de data zelf. Ingevoerde gegevens geeft de View door (en slaat deze dan ook niet zelf op).

Tussen het Model en de View zit de Controller. Deze bepaald wat er gebeurd. Voor het tonen van een gegevens op een pagina, zal de Controller opdracht geven aan het Model om bepaalde gegevens aan te leveren. Als alle gegevens binnen zijn, dan zal de Controller de data doorgeven aan de View om te tonen.

Als de gebruiker in een formulier gegevens heeft ingegeven dan zal de View de gegevens doorgeven aan de Controller. Deze zal de data snel controleren (is het een nummer, is het een geldig formaat postcode), als er fouten in zitten dan zal de Controller dit direct terugmelden aan de View om een error melding te tonen aan de gebruiker. Als de data juist is, dan zal de Controller het Model opdracht geven om de gegevens (na extra controles) op te slaan.

Dit geeft ook de mogelijkheid om als de data veranderd, vanuit het Model een bericht komt dat de data is veranderd. De Controller kan dan besluiten of het nodig is om de View te updaten. In dat laatste geval zal de View dus altijd de actuele gegevens tonen.

Met name in webpagina's en webapplicaties ie het MVC model erg populair. Dat komt omdat er op iedere pagina een aanroep is naar de Controller. De Controller kan aan het Model vragen wat er nodig is aan data voor die betreffende pagina en geeft die dan door aan de View.

Als de data is ingegeven in het formulier/knop in de View, dan gaat de gegevens naar de Controller, die dan kan besluiten om de data op te slaan en al dan niet een andere pagina te tonen.

De originele beschrijving is erg strikt. Vanuit het oorspronkelijke model zijn er enkele strikte regels.

Hoe strikt je met iedere regel omgaat, ligt aan jezelf, of het bedrijf/organisatie waar je werkt. Ik ben een groot voorstander van de code opgedeelt houden volgens de regels.

Hoe strikt je met de regel omgaat, ligt aan jezelf. :

De View mag nooit direct in het Model lezen of schrijven

De View krijgt immers alle data via de Controller aangereikt. Ik handhaaf deze regel helemaal. Ook voor de Controller, hoewel je in Laravel functionaliteit hebt, waarbij in de Controller controles kunnen worden gedaan op uniekheid van gegevens in het Model. Bijvoorbeeld om te voorkomen dat een email adres dubbel gebruikt kan worden ingegeven. Dit is om de gebruiker zo snel mogelijk feedback te geven op de invoer.

Het Model mag geen gegevens tonen of invoer vragen.

Dat is immers de taak van de View. Uitzondering hierop zijn soms log en debug berichten. Bij het ontwikkelen van programma's is het vaak handig om te zien, welke data er in het Model aankomen, dan kan uitvoer erg nuttig zijn. Bij het in productie nemen van software zorg ik ervoor dat deze tijdelijke uitvoermeldingen uit de code zijn verwijderd.

De View verwerkt geen gegevens

De View krijgt alle data aangeleverd. Dus alle artikelen in het winkelwagentje. De prijzen en ook de btw en de totaalprijs. De View gaat dat niet zelf uitrekenen, want de View weet niet vanuit welk land de gebruiker besteld en weet dus ook geen BTW percetages voor dat land.

De Controller bepaald wat er moet gebeuren en stuurt acties

In de database staat het aantal producten op voorraad. Als iemand meerdere producten besteld, dan is het aan het Model om de bestelling goed te keuren. Het is vaak verleidelijk om dat in de Controller te laten doen, maar dat is dus niet in lijn met het MVC model.

Het Model bevat de gegevens van de applicatie en de bedrijfslogica

Voor het berekenen van korting in een website moet het Model allerlei bedrijfsgegevens kennen (of een gebruiker een bepaald abonnement heeft, of er voor een bepaald bedrag is besteld etc. Dit zijn allemaal gegevens die enkel beschikbaar zijn in het Model. Daar zit dan ook de logica.

Om te bepalen of iemand volwassen is (en een bepaald artikel mag bestellen) mweet het Model de opgegeven geboortedatum en kan uitrekenen of de gebruiker een leeftijd van 16+, 18+ of 21+ heeft, afhankelijk van het soort artikel.

In het begin kan het erg betuttelend lijken. ALs je echter ervaring krijgt in het werken met MVC dan kom je erachter dat onderdelen vaak hergebruikt kunnen worden. Dat scheelt heel veel codeerwerk. En omdat de logica losstaat van de knoppen en de Model functies, is alles makkelijk testen.

Het is populair om te zeggen dat je het MVC model ondersteunt. Echter veel frameworks zeggen het te zijn, maar zijn in werkelijkheid helemaal geen MVC frameworks. Bijvoorbeeld ASP.NET Core en Ruby on Rails, claimen beide dat ze MVC gebruiken, terwijl dat niet het geval is. In deze frameworks zit heel veel (te veel) Model functionaliteit gewoon in de Controller. In die frameworks in het Model niet meer dan een eenvoudige database koppeling. Daardoor is de scheiding van functionaliteit niet aanwezig.

Het is een beetje als zeggen dat je alles vastschoeft, terwijl je de schoefmachine alleen gebruikt om een spijker in een plank te slaan.

De informatie op punthooft is en wordt met zorg en liefde samengesteld. Desondanks kunnen wij niet garanderen dat de inhoud volledig, juist of actueel is. De gebruiker is zelf verantwoordelijk voor het verifiëren van de juistheid van de gepresenteerde informatie. Wij aanvaarden geen aansprakelijkheid voor eventuele fouten, onvolledigheden of verouderde informatie. Ook aanvaarden wij geen aansprakelijkheid voor schade die voortvloeit uit het gebruik van punthooft of het vertrouwen op de informatie op punthooft.