Ik ben om te leren OOP te programmeren met php een forum aan het maken.
Wat is nu de beste methode om je objecten te vullen met de data uit de database? Moet je een constructor (of aparte functie) maken met daarin de SQL om je hele object te van zijn data te voorzien door bijvoorbeeld een id mee te geven? Of is het de bedoeling dat je buiten het object een query uitvoert en d.m.v. je setters de data in je object pompt?
Na lang denken en wikken en wegen ben ik hier nog steeds uit.
Globals kunnen in de weg zitten wanneer je het overzicht kwijtraakt, en het aanwijsbare nadeel is dat je niet duidelijk terugvindt waar er een waarde aan wordt toegekend.
Gebruik jij 1 user-object in je applicatie (en dat ligt nogal voor de hand binnen de context van een webrequest), dan is een global volstrekt legitiem. Om te lezen wel te verstaan. Wordt er op diverse plekken in je toepassing een nieuwe user in gezet, dan klopt er weer iets niet (iets wijzigen aan het *user-object* waarnaar de global verwijst is weer hartstikke OK).
De Doctrine Entity Manager regelt de 'persistence' van de gekoppelde 'entities'. Alle Domain Objects (entities) die je met $em->persist($object) aan de EM koppelt, blijven behouden in de laatste staat.
Wanneer je dus een nieuw User object koppelt en het emailadres verandert (de volgorde maakt niet uit), blijft dat emailadres veranderd in de daarop volgende requests.
In de EM kan een object 2 statussen hebben (+ nog 2, die er nu niet toe doen).
- Nieuw, er wordt dus een insert uitgevoed
- Attached, een object is met de EM opgehaald en gewijzigd. De EM vergelijkt het origineel met de gewijzigde versie en updated de wijzigingen naar de DB.
Wanneer een object wordt opgehaald, gebruikt de EM reflection om de properties te vullen. Zo heb je minder getters/setters nodig en kan je de constructor gebruiken voor het maken van nieuwe objecten.
Hoe een object in de DB weergegeven moet worden, stel je in in ofwel phpDoc blocks, ofwel een XML of YAML bestand.
Om objecten op te halen maak je gebruik van Repositories. Hierin kan je ingewikkelde SELECT DQL (een SQL variant, maar dan nuttig voor gebruik in een ORM) queries opslaan.
