MVC een last of een een zegen, of allebei
Ik dacht… Laat ik es naar MVC kijken. En dat viel me niet mee. Onduidelijkheid en verwarring, dat is wat me ten deel is gevallen.
[1] https://code.tutsplus.com/tutorials/mvc-for-noobs--net-10488
Daar heb je niet zo veel aan. Behalve dat dit verhaal duidelijk maakt wat de persoonlijke opvatting van de schrijver is: De gebruiker spreekt de Controller aan en alleen de Controller en uitsluitend de Controller. In dat opzicht is het plaatje veel zeggend.
[2] https://www.sitepoint.com/the-mvc-pattern-and-php-1/ [en deel 2]
Dit is andere koek! Deze schrijver geeft inzicht in Hoe je MVC implementeert. En dat verhaal maakt opeens heel veel duidelijk. MIJN interpretatie natuurlijk.
MVC is een concept! Een concept ten aanzien van functie scheiding; het heeft helemaal niets, maar dan ook echt niets, van doen met de implementatie van dit concept.
Functie scheiding is echt niet nieuw. Dat het in SmallTalk voor het eerst in computer science naar voren komt, is eigenlijk rijkelijk laat. In accountants kringen is het concept ten minste al honderd jaar bekend. Het concept is simpel; de Romeinen kenden het ook al: ‘divide et impera’, verdeel en heers. En dat is wat je doet, met alle voordelen daarvan.
De implementatie van het concept is weer andere koek. Er zijn vier entiteiten die samen ‘iets’ doen: User, Controller, Model en View. De ene schrijver laat de User altijd de Controller en alleen de Controller aanspreken, de andere vindt dat het aanspreekpunt soms bij de View kan liggen. Ze zijn het er over eens dat de User nooit het Model aanspreekt.
[3] https://phpro.org/tutorials/Model-View-Controller-MVC.html
De schrijver van dit artikel levert, naar zijn zeggen, een MVC-framework; what ever that may be. Ik heb het nog niet na-gebouwd, maar op het eerste gezicht lijkt dat de moeite waard. We gaan het zien.
Natuurlijk is dit weer niet de enige manier om MVC te implementeren, dat verwacht ik ook niet. Zo veel zielen, zo veel vreugd ( nou ja?).
Wellicht hebben andere nieuwkomers iets aan dit verhaal. Ik heb mijn duit in het zakje gedaan en vertrouw erop dat anderen, met mij, inzien dat het de verschillende implementatie vormen zijn die het concept onduidelijk en verwarrend maken.
[3] https://phpro.org/tutorials/Model-View-Controller-MVC.html
Het is veruit de beste tutorial die ik tot dusver ben tegengekomen. Dank daarvoor Ward!
Het is maar goed dat er een source bij zit want in het verhaal zitten een aantal vervelende foutjes. Niet echt ernstig, maar je zoekt je een aap zonder source.
Waterson levert een werkend voorbeeld van een MVC implementatie middels een framework af. Zeer leerzaam. Hij maakt ook duidelijk waar zijn persoonlijke voorkeur zit: Hij vervaagt de grens tussen Model en Controller. Dat is prima, maar niet iedereen zegt het zo duidelijk en in een leerproces is dat wel zo handig.
Twee zaken vind ik opvallend:
1.
'DE' Controller blijkt niet te bestaan: het is een hele ceel van controllers, voor elke pagina van de site één. In een beetje applicatie kan dat aardig oplopen.
2.
De Router komt in het MVC concept niet voor. Maar dit blijkt wel het meest omvattende onderdeel van deze implementatie te zijn. Had ik van te voren nooit bedacht.
Deze exercitie heeft mij veel duidelijk gemaakt, heel leerzaam. Nogmaals dank voor deze tutorial, Ward!
Wil graag met het MVC gaan werken maar heb hier op dit moment nog niet mee gewerkt. De input van anderen kan daarbij erg van pas komen.
Ik mis alleen wat uitleg die ik zelf wel belangrijk vind om schone code te krijgen die portable en onderhoudbaar is, zeker voor beginners.
In PHP is een MVC framework/applicatie al snel een MVP (Model-View-Presenter) framework/applicatie.
Dit StackOverflow antwoord legt het verschil mooi uit.
De controller/presenter (in PHP) is de "brug" tussen de view en het model en configureert beide kanten op.
De enige taak is het doorsturen van data uit de browser aan het model zodat het daar verwerkt kan worden (opslaan van het model laat ik even buiten beschouwing) en het inlezen van het model om deze om te zetten naar iets wat de view begrijpt. Een "lijmlaagje" dus.
Het "Model" is in MVC/P ook geen class maar een layer, een verzameling aan classes die samen de echte wereld modelleren en abstraheren.
Alle business-logic (oftewel de echte-wereld regels/use-cases) staan dan ook in het model en niet in de controller, een valkuil waar veel beginners in trappen wat resulteert in het "fat controller, thin model" probleem.
Een handig en belangrijk principe om dat te handhaven (en dit geld m.i. voor elke OOP applicatie) is het single responsibility principe: een class/method heeft maar 1 taak.
Houd er ook rekening mee dat een centraal "registry" vaak als antipattern word gezien, ook omdat het vaak als singleton word geimplementeerd. De moderne/OOP manier om dit te ondervangen is middels dependency injection (DI) containers en factories.
Edit:
Kleine toevoeging op de genoemde design patterns en principes: Het zijn geen keiharde regels waar je je aan moet houden maar meer richtlijnen/handvatten om dingen makkelijker en duidelijker te maken.
Gewijzigd op 22/01/2020 14:34:57 door Thom nvt
Dank voor de reactie.
Ik heb deze tut nu twee keer gemaakt; de laatste keer met het veranderen van een aantal variabele namen.
Dat heeft het voordeel dat ik dan kan zien waar het fout gaat en de flow/structuur van de code beter begrijp.
OP laatst, bij het kopje 'VIEW' wordt het verhaal wel erg rommelig en blijft er van de duidelijkheid niet veel over.
Niettemin: als eerste exercitie in een MVC-implementatie c.q framework, zeer leerzaam.