MVC model

De model fungeert als een laag tussen (de rest van) je applicatie en de database. Ik ben gewend -en dat hoeft niet perse een gouden regel te zijn- om een model aan te maken per tabel in de database. Dus stel je hebt in de database een tabel 'users' dan maak ik een UserModel welke ik vul met methods die ik nodig heb. Bijvoorbeeld de methods 'getAllUsers()' en 'getAdmins()' welke beiden een array met User objecten terug leveren. Wel ontstaan hierin overlappingen doordat sommige tabellen in de database 'keuzenlijstjes' zijn voor andere tabellen (bijv. een tabel provincies die alle provincies bevat en gebruikt wordt bij het aanmaken van een gebruiker). Ik ga dan geen ProvinceModel class maken maar integreer dit gewoon mee in de UserModel met een JOIN in de query.

Verder gebruik ik die UserModel class waar ik dat wil. In het login-systeem, in het berichten-systeem en als ik wil op iedere pagina.

[size=xsmall]Toevoeging op 14/04/2019 13:02:56:[/size]

Overigens heeft een goed framework natuurlijk een base model die in de belangrijkste behoeften voorziet zoals:

-findAll()
-findBy(array $criteria, array|null $orderBy = null, int|null $limit = null, int|null $offset = null)
-findOneBy(array $criteria, array $orderBy = [])
-count(array $criteria)

[size=xsmall]Toevoeging op 14/04/2019 13:06:02:[/size]

Enne.. eigen framework? reinventing the wheel?

Een stoomcursus Symfony of Laravel duurt minder lang ;-)

Natuurlijk helpt het om ook te kijken naar andere frameworks, maar het maken van een eigen framework kan ik ten zeerste aanraden, als je daar de tijd voor wilt nemen. Je moet er niet van uit gaan dat je framework meteen beter is dan wat er is. Maar je kunt er veel van leren, je houdt alles zelf in de hand en uiteindelijk kan je je eigen framework beter maken dan wat er al is.

Om te beginnen moet je je afvragen of jouw applicatie synchroon wordt of niet, dat scheelt heel veel refactoring achteraf. Kijk naar https://amphp.org voor meer informatie over aynchroon programmeren.
Bij twijfel, maak je je applicatie 'gewoon' multithreaded zoals dat standaard is in PHP.

Voordat je begint is het nodig om te snappen dat MVC gewoon niet werkt voor PHP applicaties. Veel mensen snappen het ook niet en dus lees je overal weer wat anders. Voor meer uitleg zie de serie 'Model-View-Confusion' van Tom Butler op https://r.je/views-are-not-templates . MVC was nooit bedoeld voor stateless programmeren wat PHP is.

Het helpt om te weten dat je vooral niet blind moet varen op wat mensen voorschrijven, ook al is het Google zelf. Neem bijvoorbeeld dependency injection. Dat werkt ook niet. Als je dat serieus zou willen doen dan moet je bijna elk object een database-verbindingsobject meegeven en andere objecten. Dat wordt uiteindelijk zo veel dat men dat ook is gaan automatiseren. Om de 'dependency injection hell' nog zo veel mogelijk te voorkomen, maar mooi is het niet.

Wanneer je verder bouwt aan je eigen framework kom je er achter dat Laravel ontzettend beperkt is (maar simpel genoeg voor veel dingetjes) en dat je het zelf beter kan. En dat Symfony het meest uitgebreide framework is, maar ontzettend traag vergeleken met maatwerk code. Reflection klinkt leuk maar kan je vanwege snelheid beter vermijden.

Wanneer je je een poos hebt verdiept in frameworks ontdek je dingen die werken, zoals bepaalde database objecten, schermwidgets, etc. en dingen die niet werken, zoals niet flexibele templates.
En wanneer je je hele framework hebt uitgewerkt kom je er achter dat er nieuwe technologie is waardoor je een betere UX krijgt met meer JavaScript, tot en met een PWA aan toe. Een site ter inspiratie: https://acko.net (geen PWA)
En als je uiteindelijk alles al een keer gezien hebt ga je over op WebAssembly.

MVC is inderdaad slecht geschikt als architectuur, maar wel bruikbaar als design pattern. Gebruik MVC liever niet als totaaloplossing, maar uitsluitend als deeloplossing.

In Patterns of Enterprise Application Architecture van Martin Fowler is MVC bijvoorbeeld slechts één van zeven web presentation patterns:

- Model View Controller
- Page Controller
- Front Controller
- Template View
- Transform View
- Two-Step View
- Application Controller

Voordat je definitief voor MVC kiest, moet je tot de conclusie zijn gekomen dat andere oplossingen voor jouw specifieke applicatie minder geschikt zijn.

Als je alleen een hamer hebt, ziet elk probleem eruit als een spijker...

Ben het niet helemaal met je eens op dit punt.
Als ik zoek naar 'consensus' op internet, is het wel dat PHP frameworks in meer of mindere mate MVC moeten zijn. Welke vergelijkingssite ik ook opentrek, ze hebben het allemaal over de MVC-architectuur van het raamwerk. Wikipedia over Web Frameworks: 'Most web frameworks are based on the model–view–controller (MVC) pattern'

Daarbij zijn er vele sites over design patterns. Het zijn er gewoon te veel. Dus voordat je überhaupt tot de conclusie kunt komen of het gekozen reeds bestaande design pattern wel het meest geschikt is voor jouw probleem, moet je al een guru zijn en alle andere patterns doorgronden.

In mijn ervaring is er eigenlijk geen enkele goede design pattern, daarom zijn er ook zo veel. Het is een bepaalde manier, een bepaalde stijl om een soort probleem op te lossen. Het is zeker nooit de enige manier om een probleem op te lossen. Daarom vergelijk ik design patterns ook wel met bouwstijlen. Uiteindelijk moet je programma aan eisen voldoen, zo van zo moet het werken. Maar hoe het dat doet, zal een klant niet uitmaken. Wil je liever pattern X dan Y? Ook best.
Maar voordat je daar achter bent moet je wel eerst ervaren hebben dat MVC, zoals meestal wordt geadverteerd binnen de PHP sector, gewoon een slecht idee is.

Ik denk dat het belangrijk is om het juiste ontwerppatroon te kiezen voor uw project. Als u een klein project ontwikkelt, kan MVC te complex zijn. In dat geval kunt u een eenvoudiger sjabloon gebruiken, zoals Model-View (MV).