Ik haat MVC

Ja je leest het goed! Ik haat MVC. Het is een gedrocht, het is onzinnig en is zijn doel ver voorbij geschoten!

Ben je er nog? Durf je het aan om onderbouwde kritiek op het beroemde en ozo geliefde MVC te lezen? Zo niet, skip dan vooral door en blijf je tijd verspillen aan MVC, routing, configs etc.

Vergis je niet, ik kén het MVC model. Ik heb ermee gewerkt en moet er weer mee werken. En dat doen we braaf. Maar telkens raak ik meer overtuigd van mijn (eigen)wijze arrogante zelf. Gelukkig zijn er al een paar mensen die het ook wagen om kritiek te hebben.

Het is ook compleet onnodig! Want voordat iemand ooit MVC bedacht, wee hem/haar… waren er al échte programmeurs die wisten dat je templates en logica van elkaar moest scheiden. Dat deed ik al in 2001! Toen bestond het Zend Framework nog niet eens, php4 was pas net uit. Laat staan dat er andere frameworks waren.

Gedrocht?

Ja een gedrocht. Een Controller is een alleskunner, evenals het Model. De view is meestal nog de enige, die zich aan het oude principe ‘1 script 1 doel’ houdt.

Waarom staat alles van 1 module in 1 Controller? Waarom staat alle logica van die module in 1 Model? Is dat overzichtelijk? Heb je dan alles bij elkaar? Vindt je?

Waarom wil ik code inladen voor deleten, tonen, aanmaken en bewerken van iets, terwijl ik steeds maar 1 ding tegelijk nodig heb? Is dat DRY? Zijn dat mooie kleine classes? Is het daarmee duidelijk wat dat script allemaal doet?

Deden we dat vroeger niet net zo? Nee? Ok, toen maakte men (ik niet!) 1 script per module. Zet alles binnen een stel if’s en we hebben onze module. Met MVC hebben we dat helemaal verbeterd, we gebruiken nu wel 3 scripts! jaja….

Is dat volgens het principe dat een class of functie maar EEN DOEL mag hebben?

Ok, Voorbeeld

Stel je hebt een module contacten. Hoe vaak wil je een contact of een onderdeel daarvan verwijderen? Hoe vaak wil je nieuwe contacten aanmaken of onderdelen toevoegen? Op hoeveel verschillende manieren? Hoe vaak wil je contacten tonen op heel veel verschillende manieren?

Laten we een rijtje maken en het in verhouding zetten per contact-record voor het gemak:

• aanmaken: 1x per onderdeel op hooguit 2 of 3 manieren
• bewerken: soms, zeg 10x (per onderdeel) op hoogtuit 2 of 3 manieren
• verwijderen: niet of hooguit 1x (per onderdeel) op 1 manier misschien 2
• tonen: honderden keren op tientallen manieren.

Alle code die hiervoor nodig is, moet verwerkt worden in 1 Controller en 1 Model en meerdere views. Tenminste dat is het hoofd principe van MVC. Dan hebben we het nog niet eens over overlappende data…

Als ik een contact op 1 specifieke manier oproep, wordt dus alle overige code ook ingeladen. Zelfs de delete functies… Wat nog eens een veiligheidsrisico is! Je zal maar een junior programmeur hebben die de boel verprutst. Oh ja, daar hebben we unit-testing voor. Ook al zo’n over de top onzin. Maar daarover een andere keer.

Symptoombestrijding

Het is toch niet erg dat alles ingeladen wordt? Want we hebben caching. We zorgen dat de server voldoende capaciteit heeft; is tegenwoordig niet duur meer, wordt er dan schaapachtig gezegd. Dat zeiden we vroeger ook, maar dan andersom: het is te duur om netjes te programmeren, dus doen we het WET. Testen is ook te duur, zolang het werkt, maken we geen slapende honden wakker.

Oftewel: alle voor negatieve effecten en symptomen zoeken we wel een pleister om het gat te dichten.

Wat zijn dit voor slechte argumenten? Waarom niet gewoon goed programmeren volgens de oude principes: DRY en 1 script doet 1 ding.

Wat zouden de systemen dan kleiner kunnen worden en geen caching nodig hebben.
Frameworks kunnen veel eenvoudiger.
Programmeurs zijn geen config-goochelaars meer, maar kunnen zich weer vastbijten in normaal en serieus programmeren.

Life beyond MVC?

Hoe zou onze code er dan uitzien, nou heel simpel:

• Voor het aanmaken en bewerken hebben we 1 basisscript per data-eenheid, eventueel met varianten als er meerdere manieren nodig zijn.
• Voor het verwijderen van een data-eenheid hebben we 1 script.
• Voor het tonen van de data hebben we zoveel scripts als nodig zijn….

Voorwaarden:

• Elke pagina of blok heeft uiteraard zijn eigen template
• De scripts hebben een vaste herkenbare structuur
• Er zijn duidelijke naming-conventions
• De scripts laten de generieke taken door het framework uitvoeren.

Voordelen:

• Kleine overzichtelijke scripts
• Weinig routing config nodig, door goede naming-conventions weet de autoloader waar het zijn moet
• Het doel van het script is gelijk duidelijk door de naamgeving
• Een stuk veiliger omdat bewerken/deleten en tonen van data in aparte scripts staan
• Veel minder caching nodig
• Veel meer controle over wat het script wel en niet moet doen
• Veel flexibeler
• Niet afhankelijk van configuratie
• Veel minder afhankelijk van het framework
• Eenvoudig te debuggen, want je bent met 1 script bezig

Nadelen:

• De programmeur kan spaghetti code bakken > die moet goed leren programmeren of iets anders gaan doen
• Je moet meer zelf doen > is dat zo erg?
• Je moet meer nadenken…. als je dat liever niet doet, doe het dan niet hier 😉

Nog niet overtuigd?

Lees de spaarzame artikelen van anderen die het wagen om ook kritiek te hebben:

• Problem or Solution van Sitepoint
• I hate MVC van nerdr
• Design patterns i hate op Zend.com itself

Ben je er nog?

Geschokt? Eens? Oneens? Laat het me weten. En overtuig me!