[PHP] relaties met DAO en VO

[2playgames]

Voor de opslag van persistente data gebruik ik de design patterns Value Objects (ookwel Data Transfer Objects) en DAO (Data Access Objects). Voor elk domeinobject heb ik een VO klasse die voor elke kolom een veld heeft, als volgt:

code:

<?php class Service {
    
    private $id, $member, $project, $fullname;
    
    // setters
    
    public function setId($id) {
        $this->id = $id;
    }
    
    public function setFullname($fullname) {
        $this->fullname = $fullname;
    }
    
    public function setMember($member) {
        $this->member = $member;
    }
    
    public function setProject($project) {
        $this->project = $project;
    }
    
    // getters
    
    public function getId() {
        return $this->id;
    }
    
    public function getFullname() {
        return $this->member;
    }
    
    public function getMember() {
        return $this->member;
    }
    
    public function getProject() {
        return $this->project;
    }
    
} ?>

en een DAO klasse, die voor een specifiek domeinobject functies heeft als get, findByBlabla en insert,update,delete.

nu zit ik met de volgende kwestie; de eigenschappen Project en Member in de klasse Service zijn verwijzingen naar andere domeinobjecten. momenteel geven de functies gewoon de waarde van de foreign key terug, maar idealiter zou ik meteen het juiste object willen hebben. hierbij is een probleem:

- ik moet databasefunctionaliteit in de domeinobjecten gaan zetten om on-the-fly het juist object op te vragen
- OF ik moet bij het SELECTen van objecten meteen alle gerelateerde objecten meefetchen. in geval van 1-op-veel of veel-op-veel relaties kost dit veel tijd, terwijl het vaak overbodig is

beide opties zie ik dus niet echt zitten. kan iemand met ervaring in deze patterns mij hierover adviseren? op internet is wel genoeg te vinden over DAO maar niks over relaties.

bedankt

[YopY]

Je zou kunnen kijken naar hoe bekende PHP O/R mappers (of O/R mappers in het algemeen) dit probleem oplossen. Het moet wel op te lossen zijn in een enkele query, maar het automagisch opbouwen van zo'n query kan nogal ingewikkeld worden.

[pgussow]

Je zou ook een andere functie daarvoor kunnen genereren:
loadProjectObject() en loadMemberObject() en dan de DAOs van member en project lezen.

[YopY]

pgussow schreef op maandag 28 januari 2008 @ 09:44:
Je zou ook een andere functie daarvoor kunnen genereren:
loadProjectObject() en loadMemberObject() en dan de DAOs van member en project lezen.

Het probleem daarmee is performance. Met MySQL en vergelijkbare DBMSen zou je het gehele hoopje in een enkele query op kunnen halen: op de manier die je voorstelt zou het ook wel werken, maar je zou er drie queries voor nodig hebben. Ik weet niet hoeveel het uit zou maken, maar het kan veel uitmaken qua performance.

[2playgames]

Ik heb voorlopig extra methoden aan de Value Objects toegevoegd, die weer methoden als getProjectFromService(Service $service) in, in dit geval, ProjectDao aanroepen. Dit is inderdaad niet goed voor de performance (N+1 queries), en ook niet zo OO, maar het werkt en ik kan weer even vooruit. Voortijdig optimaliseren is immers een doodzonde
Als het een probleem wordt kan ik er alsnog later naar kijken.

[whoami]

Het N + 1 probleem oplossen noem ik nu niet premature optimization ofzo hoor ....

Je kan alle informatie die je nodig hebt in één keer uit de DB halen, en dan bij het construeren van je domain objects de juiste gegevens er aan toe kennen.