[PHP/OOP] Waar database logica laten?

[0fbe]

Ik ben al een tijdje met PHP aan het prutsen en ken de achtergrond van OOP vanuit mijn C++ theorie. Ik zit echter met een twijfel geval:

Je wilt vanuit PHP optimalisatie technisch zo min mogelijk query's naar een database doen en toch je code zo goed mogelijk OO-houden. Wat is hiervoor dé manier:

Manier 1: Classes zijn 1:1 handlers van de database:
Bij elke get en set wordt de database aangeroepen: Dit valt natuurlijk al snel af omdat dit niet optimaal is. Wel garandeerd het dat een object altijd gelijk is aan zijn representatie in de database.

Manier 2: Classes worden gevuld door het object waar ze in leven:
Neem als voorbeeld een object bibliotheek. Wil men een object boek dan doet roept men op het object bibliotheek getBoek(x) aan wat dan het object retourneerd. Bij het retourneren is er geen garantie op goede actuele data en geen koppeling naar de database meer. Als er dus wijzingen worden gedaan op het object moeten deze later worden weggeschreven. Dit kan dan door de bibliotheek of het boek gebeuren? Logische wijs als bibliotheek leest zal deze ook moeten schrijven.

Manier 3: Classes worden gevuld door een handler.
Een boek kan worden aangeroepen door getBoek op de handler uit te voeren. Ook wegschrijven wordt afgehandeld door de classes.

Naar mijn idee is manier 3 de netste oplossing maar de vraag is of jullie die mening met mij delen.

[whoami]

Kijk eens naar het repository pattern.
Dat vind ik nog altijd de beste / netste manier.

Je hebt een 'repository' per 'aggregate root'. Waarbij een aggregate root dus een business entity is, die uit meerdere objecten kan bestaan.
Je 'praat' tegen de repository, en deze returned je de entity/entities, of, je geeft entities door aan die repository die deze gaat gaan saven, bv.
De repository is dus een abstractie van je data-store.

[Anoniem: 341065]

Hoe verwacht je praktisch een probleem te hebben met het feit dat de versie van 'Boek' die je ooit uit de database hebt gehaald inmiddels door iemand anders gewijzigd is? Misschien een vooroordeel van me, maar meestal zie ik PHP gebruikt worden in websites of webapplicaties die slechts een fractie van een seconde bestaan op het moment van de request tot het terugsturen van de respons. En hoe erg is het dat in die fractie van een seconde wellicht iemand een oude versie van het boek krijgt?

Stel dat je een server achtige applicatie hebt in bijvoorbeeld Java, dan moet je inderdaad zorgen dat de versie van Boek die je in je geheugen hebt altijd up to date is. Je kunt dan op allerlei manieren zoals Observer-Observable een notificatie sturen naar het boek dat hij een actuele versie van zichzelf uit de database moet gaan halen. Maar dat heeft te maken met het feit dat de informatie over Boek een hele grote kans loopt om verouderd te zijn op het moment dat de applicatie al een dag draait.

Eigenlijk kun je pas zeggen wat de beste oplossing is als je een vastomlijnd plan hebt van de applicatie die je wilt gaan bouwen. En dan het patroon gebruiken wat op dat moment het beste werkt. Sowieso gaan een hoop van je goede voornemens vaak al het raam uit als je met HTTP moet gaan werken

[ Voor 6% gewijzigd door Anoniem: 341065 op 20-01-2010 10:05 ]

[Anoniem: 42791]

@Whoami: bestaat er zo'n repository oplossing voor PHP? Ik ben daar een tijdje naar op zoek geweest en zit nu zelf wat te bouwen. Ik ben al weken bezig met het opslaan van TypeDefinitions, PropertyDefinitions, het valideren van die dingen, het maken van een boom om die objecten in te hangen en dan heb ik nog niet eens over access control nagedacht bijvoorbeeld.

Voor de topicstarter: ik begrijp het verschil tussen 2) en 3) niet zo. In elk geval is het voordeel van een repository dat zo'n ding compleet onafhankelijk is van de gegevens die je wil opslaan. Je ziet dus nooit een addBoek() of getBoek() methode, maar eerder een addNode($boekNode) functie. Dat houdt je datalaag lekker onafhankelijk van de applicatie die je erop bouwt Je kunt bijvoorbeeld op elk moment besluiten dat je ook Auto's wil gaan opslaan, zonder dat je dan in de datalaag hoeft te knutselen.

[whoami]

Anoniem: 42791 schreef op woensdag 03 februari 2010 @ 17:55:
@Whoami: bestaat er zo'n repository oplossing voor PHP?

Hoezo ? Een repository is een pattern, en dat moet je dus zelf implementeren.
In welke taal je dat doet, boeit niet.

[Anoniem: 42791]

whoami schreef op woensdag 03 februari 2010 @ 19:23:
[...]
Hoezo ? Een repository is een pattern, en dat moet je dus zelf implementeren.
In welke taal je dat doet, boeit niet.

Ik bedoel een oplossing zoals Jackrabbit of MMBase, maar dan voor PHP. Zo'n apparaat zelf bouwen is niet niets.

[whoami]

Anoniem: 42791 schreef op woensdag 03 februari 2010 @ 23:21:
[...]


Ik bedoel een oplossing zoals Jackrabbit of MMBase, maar dan voor PHP. Zo'n apparaat zelf bouwen is niet niets.

Wie heeft het hier over 'een apparaat' ?
Ik heb het over het repository pattern, geen 'content' repository, of source repository.

Ik snap niet hoe je bij Jackrabbit komt, aangezien dit imho niets terzake doet in dit topic / niet aan bod is gekomen in de TS.

[whoami]

Voor de topicstarter: ik begrijp het verschil tussen 2) en 3) niet zo. In elk geval is het voordeel van een repository dat zo'n ding compleet onafhankelijk is van de gegevens die je wil opslaan. Je ziet dus nooit een addBoek() of getBoek() methode, maar eerder een addNode($boekNode) functie. Dat houdt je datalaag lekker onafhankelijk van de applicatie die je erop bouwt

Ik zie daar helemaal het voordeel niet van in ?
Je code moet juist expliciet zijn, waarmee ik bedoel dat je de code moet kunnen lezen, en het moet duidelijk zijn wat die code doet. Je 'datalaag' is toch specifiek voor je applicatie, dus waarom zou je die zo generiek gaan maken ?

[0fbe]

Anoniem: 42791 schreef op woensdag 03 februari 2010 @ 17:55:
Voor de topicstarter: ik begrijp het verschil tussen 2) en 3) niet zo. In elk geval is het voordeel van een repository dat zo'n ding compleet onafhankelijk is van de gegevens die je wil opslaan. Je ziet dus nooit een addBoek() of getBoek() methode, maar eerder een addNode($boekNode) functie. Dat houdt je datalaag lekker onafhankelijk van de applicatie die je erop bouwt Je kunt bijvoorbeeld op elk moment besluiten dat je ook Auto's wil gaan opslaan, zonder dat je dan in de datalaag hoeft te knutselen.

Het verschil tussen 2 en 3 zit hem vooral in de overige functies van zo'n klasse: Bij 2 heeft een klasse naast de functionaliteit om objecten op te halen uit een data-bron ook nog eigen eigenschappen. Bij 3 is een klasse gespecialiseerd om objecten (van een bepaald type) uit de data-bron op te halen en heeft verder geen eigen functionaliteit of eigenschappen.

[Jory]

Bij de 2de oplossing doet een klasse dus meerdere, verschillende dingen, wat ingaat tegen separation of concerns en single responsibility. De 3de oplossing is daarom dus beter als de 2de.

[Anoniem: 345999]

Ik verbaas me erover dat er nog niemand over MVC (Model View Controller) is begonnen. Zowel ZendFramework, CakePHP als CodeIgniter zijn MVC frameworks.

In het geval van Model View Controller zit de database logica in de Model.

Ik zweer bij MVC en raad je aan het volgende te bekijken: http://www.bhartisoftland...ill-sets/gifs/mvc-php.png

Je browser komt PHP binnen en wordt via URL routes naar de juist controller gebracht. De controller bepaalt wat er precies wordt opgevraagd en of er bewerkingen moeten worden gedaan. Hij instantiate wat classes/objecten indien nodig en praat er mee.

Die classes/objecten zijn Models, die praten met je database en je filesystem. Welke van de 3 mogelijkheden die je noemt, hier worden ingezet, staat geef ik toe niet vast.

Vervolgens wordt er op basis van de opgehaalde data, een View gestart. Dat is je HTML.

[ Voor 5% gewijzigd door Anoniem: 345999 op 18-02-2010 23:18 ]

[Janoz]

De reden dat nog niemand over MVC is begonnen is omdat MVC een GUI pattern is en geen DL pattern.

[Anoniem: 345999]

Huh?

MVC is begonnen als een GUI pattern, echter Zend, CakePHP en CodeIgniter zijn front-end en back-end systemen. In een web-applicatie die MVC hanteert is de View is de "GUI", de Controller de logic en de Model de database/filesystem handlers.

Wat is een DL-pattern?

[ Voor 13% gewijzigd door Anoniem: 345999 op 19-02-2010 12:05 ]

[Ssander]

Een DL-pattern is een Data Layer pattern, zeg maar het 'model' binnen de MVC architectuur. Omdat de TS specifiek naar de database logica vraagt is niemand begonnen over MVC omdat dit veel breder is.

[Janoz]

MVC is een GUI pattern. Dat was zo en dat is nog steeds zo. het zegt helemaal niks over de datalaag. Bij MVC gaat men er van uit dat de gegevens er al zijn. MVC is een pattern dat handvatten aanbied om op die data acties uit te voeren en te bepalen hoe ze weergegeven wordt.

MVC zegt helemaal niks over de data laag.Vandaar dat je daar ook 2 type oplossingen ziet. de eerste is dat je Model een stuk intelligenter wordt (de optie 1 van de topicstarter). De tweede is dat de controller de datalaag aanspreekt om het Model te persisteren of op te halen (opties 3).

[Anoniem: 345999]

Helder. Ik houd me weer stil.