[PHP|MySQL] OOP en databases

[maartenvdv737]

Ik ben op dit moment aan het overwegen om mijn programmeermethodiek aan te passen. Ik werk nu deels object georienteerd, voor Templates, Database en Sessions.

Graag wil ik er naar toe dat practisch alles in objecten verwerkt is. Op die manier hoef ik niet voor elke applicatie een compleet nieuwe structuur op te bouwen, maar kan ik standaard objecten (en tabellen) gebruiken.

Ik weet dat PHP niet optimaal is voor OO programmeren, maar het moet toegankelijk blijven, zodat andere mensen er eenvoudig mee kunnen werken. Mijn ervaring is dat Java o.i.d. minder ingeburgerd is bij mensen die internet applicaties ontwikkelen.

Mijn probleem met deze aanpak voor zover ik dat nu kan overzien is het volgende:

Een object van een class bevat 1 ding, bijvoorbeeld een Persoon, of een Artikel.
Stel dat ik nu alle objecten wil van alle personen die vandaag jarig zijn, dan moet ik per object een query uitvoeren naar de database, dit in tegenstelling tot niet OO, waar je dat in 1 query doet.

Koppel ik het object Persoon los van de database class, oftewel, ik voer geen queries uit in die class, maar gebruik een methode als addPerson(), dan moet ik voor elke class een andere class maken die ik kan gebruiken om 1 of meerdere personen tegelijk uit de database te halen en vervolgens voor elke persoon een Object aan te maken.

Naar mijn mening is dan het voordeel van OO redelijk weg, en belangrijker, je gebruikt een aantal extra stappen om je doel te bereiken.

Ik heb begrepen dat er object georienteerde databases zijn, maar het liefst werk ik met mysql, omdat dit wijdverspreid is en weinig eisen stelt aan de hostingprovider.

Heeft iemand een oplossing hiervoor of een mening hierover met het oog op efficientie, nut e.d.?

[NMe]

maartenvdv schreef op 03 maart 2004 @ 15:01:
Koppel ik het object Persoon los van de database class, oftewel, ik voer geen queries uit in die class, maar gebruik een methode als addPerson(), dan moet ik voor elke class een andere class maken die ik kan gebruiken om 1 of meerdere personen tegelijk uit de database te halen en vervolgens voor elke persoon een Object aan te maken.

Naar mijn mening is dan het voordeel van OO redelijk weg, en belangrijker, je gebruikt een aantal extra stappen om je doel te bereiken.

Dit is juist een veelgebruikte toepassing van OO. Je maakt een class Persoon met daarin de gebruikelijke variabelen (naam, adres) en functies (setNaam, setAdres) enz, en je maakt een omvattende class Personen met daarin functies als addPersoon() en getPersonen(). Je dient zoiets zo te programmeren dat een andere programmeur die je code niet kent de class Persoon niet nodig heeft en alles met Personen kan doen.

Je hebt misschien wat extra stappen nodig om je doel te bereiken maar het heeft echt zijn voordeel. Je code wordt er veel makkelijker te begrijpen door en je hebt bij het maken van een gewoon script (als je classes dus al af zijn) een zeer minimaal stuk code nodig om 'veel' te doen.

[Skaah]

Kun je niet een tabel maken die alle attributen / properties van je object opslaat?

PHP:

class persoon
{
  var $id;
  var $voornaam;
  var $achternaam;
}

SQL:

CREATE TABLE o_persoon (
  id int (6) PRIMARY KEY,
  voornaam varchar(255),
  achternaam varchar(255)
)

Je kunt eventueel een class schrijven die de database koppeling zelf verzorgt.

[maartenvdv737]

tuurlijk kan ik zo'n tabel maken, maar vervolgens moet je beslissen of je de
getName() methode gaat vullen met een overkoepelende class Personen, ofdat je in getName() een query uitvoert om de naam te krijgen van het betreffende object.

Verder vraag ik mij af of het obslaan van alle variabelen in objecten niet een algehele vertraging impliceert die niet wenselijk is.

Afgezien van het feit dat je wellicht een overzichtelijkere structuur krijgt die makkelijker is uit te breiden, ga je naar mijn inziens flink aan snelheid inboeken (en geheugen gebruik). Je moet namelijk het object Persoon telkens vullen met alle data die de persoon heeft in de database. Vervolgens hoef ik op de betreffende pagina wellicht alleen de naam van de Persoon te weten. Dan zit ik met een object die groter is dan gewenst, en ook meer tijd kost om aan te maken.

Ik zou graag weten hoe andere programmeurs, die met grote websites en servers werken, dit ervaren.

[ Voor 19% gewijzigd door maartenvdv737 op 03-03-2004 18:16 ]

[maartenvdv737]

Ik zit net even na te denken over de class Personen, die dan zogenaamd de objecten van Persoon gaat aanmaken.

Hoe ga je nou aan Personen vertellen welke personen allemaal in Persoon opgeslagen moeten worden? Als ze nou allemaal in een groep zitten ofzo, dan kan je nog een methode maken die aan de hand van een groep_id de personen selecteerd uit de database, maar als dat niet het geval is, dan gaat dat nooit werken.

Dan moet ik elke keer als ik de personen op een andere manier wil selecteren een nieuwe methode erbij maken in Personen.

Ik kan natuurlijk de query aan de constructor meegeven, maar ja, op welk niveau ga ik die query dan weer invoeren.

[djluc]

Hoe ga je nou aan Personen vertellen welke personen allemaal in Persoon opgeslagen moeten worden? Als ze nou allemaal in een groep zitten ofzo, dan kan je nog een methode maken die aan de hand van een groep_id de personen selecteerd uit de database, maar als dat niet het geval is, dan gaat dat nooit werken.

Een groep is ook weer een object...dus je zult van het object persoon een child object moeten maken van groep.

[vaag-idee-modus ]Ik zit te denken aan een soort van tree, boom, zoals de windows verkenner. Je zou dan maar een paar kleine tabellen hebben in je database. Je krijgt dan een tabel tree, en itemtype waarmee je aangeeft wat het voor item is in de tree. Je zou dan zelfs verwijzingen e.d. in je tree op kunnen nemen. Ieder item stelt dan een object voor.

[ Voor 30% gewijzigd door djluc op 03-03-2004 19:08 ]

[Skaah]

maartenvdv schreef op 03 maart 2004 @ 18:14:
Verder vraag ik mij af of het obslaan van alle variabelen in objecten niet een algehele vertraging impliceert die niet wenselijk is.

Een beetje webserver is tegenwoordig breed uitgerust. Tenzij je zoiets als T.net host zul je niet erg snel performance problemen krijgen, lijkt mij. Maar ik ben ook maar een simpele php-prutz0r.

Afgezien van het feit dat je wellicht een overzichtelijkere structuur krijgt die makkelijker is uit te breiden, ga je naar mijn inziens flink aan snelheid inboeken (en geheugen gebruik). Je moet namelijk het object Persoon telkens vullen met alle data die de persoon heeft in de database. Vervolgens hoef ik op de betreffende pagina wellicht alleen de naam van de Persoon te weten. Dan zit ik met een object die groter is dan gewenst, en ook meer tijd kost om aan te maken.

Is

code:

SELECT voornaam FROM personen

werkelijk veel sneller dan

code:

SELECT voornaam,achternaam FROM personen

? Je selecteert gewoon een veldje meer uit een rij. Dat moet geen probleem zijn want er zitten geen joins in of dergelijke en het is dus een extreem simpele query voor je database-server. Iedere rij staat immers voor een volledig object?

Een object opbouwen is ook zo gedaan, het is bijna een kwestie van variabelen erin rammen. (Alhoewel ik niet weet hoe ingewikkeld je objecten zijn?)

PHP:

$result = mysql_query('SELECT * FROM personen');
$row = mysql_fetch_assoc($result);
$obj = new Persoon();
foreach($row as $key => $val)
{
  $obj->$key = $val;
}

Done. Zo simpel kan het zijn, mijns inziens.

Ik zou graag weten hoe andere programmeurs, die met grote websites en servers werken, dit ervaren.

[ Voor 3% gewijzigd door Skaah op 03-03-2004 20:48 . Reden: Klein bugje, beetje extra comments. ]

[Verwijderd]

Je kan bijvoorbeeld in de 'groep' class een array bijhouden met 'persoon' objecten.

[ACM]

Zoek es wat design patterns die TO (Transfer Object, ook wel VO Value Object genoemd) en DAO (Data Access Object) gebruiken. 't Is zoals met veel dingen allemaal al es eerder bedacht, in Java zijn er zelfs complete frameworks die aan de hand van een definitie een stel TO's en DAO's genereren

[maartenvdv737]

Hier staat een stukje over VO en DAO:
http://www.odi.ch/prog/design/php/guide.php

Ze zeggen dat je voor elke VO een DAO nodig hebt. Ik zie niet echt hoe die twee met elkaar in verband staan?

[ACM]

Een DAO creeert een VO uit de database en vervolgens wordt er binnen de applicatie de VO gebruikt. 't Voordeel van de VO's tov de DAO's is dat ded objecten die je voor alles (behalve de db-handelingen) gebruikt veel eenvoudiger zijn

't Nadeel is o.a. dat je steeds dubbel werk doet als je ooit es wat wijzigt natuurlijk, maar de pattern-bedenkers vonden dat blijkbaar een minder groot nadeel

[Skaah]

ACM schreef op 04 maart 2004 @ 10:50:
Een DAO creeert een VO uit de database en vervolgens wordt er binnen de applicatie de VO gebruikt. 't Voordeel van de VO's tov de DAO's is dat ded objecten die je voor alles (behalve de db-handelingen) gebruikt veel eenvoudiger zijn

't Nadeel is o.a. dat je steeds dubbel werk doet als je ooit es wat wijzigt natuurlijk, maar de pattern-bedenkers vonden dat blijkbaar een minder groot nadeel

Ik vind dit erg interessant, vooral

Generate code
99% of the code for your VOs and DAOs can be generated automatically from your database schema when you use some naming conventions for your tables and columns. Having a generator script ready saves you time when you are likely to change the database schema during development. I successfully used a perl script to generate my VOs and DAOs for a project. Unfortunately I am not allowed to post it here

[maartenvdv737]

Terugkomend op het probleem wat ik bovenin stel, het aanmaken van meerdere objecten Persoon met 1 query.

Hoe werkt dit in de praktijk met een DAO? Moet ik dan een class Persoon met PersoonDAO maken, en ook nog een class Personen met een class PersonenDAO.

Stel nu dat ik alle jarigen wil selecteren, moet ik dan een class JarigePersonen en JarigePersonenDAO maken?

Ik ben er bijna, maar ik zie nog niet helemaal hoe ik dit zo in elkaar kan zetten dat ik ook echt op lager niveau beslissingen kan maken zodat ik daar op hoger niveau niet meer mee bezig hoef. Ik wil bijvoorbeeld niet op het hoogste niveau de query gaan meegeven aan een constructor o.i.d.

[Martin Sturm]

Je zou in je DAO-class een method kunnen maken met 1 parameter waarop hij zoekt (bijvoorbeeld de datum van vandaag ofzo, je zou het ook zonder parameter kunnen doen en standaard op de datum van vandaag kunnen zoeken) en vervolgens geef je een collection met VO's terug (of een array in het geval van PHP, of een eigen iterator object ofzo, wees creatief ).

[Verwijderd]

Ik gebruik de volgende opzet: Alle code van mijn database applicatie is ingedeeld per tabel . Mijn doel was om zo min mogelijk code te hoeven schrijven per tabel.

een tabel 'persoon' met kolommen:
id, primary key auto increment
naam, varchar 100
geslacht, char 1

PHP:

class persoon extends dbrecord {
  var $id = 0; // primary key, auto increment
  var $naam = '';
  var $geslacht = 'm';

  function isMannelijk() { // voorbeeld van tabel-specifieke functionaliteit
    return $geslacht == 'm';
  }
}

class personen extends dbrecords {
  var $tablename = 'persoon';
}

Alle functionaliteit staat in de classes dbrecord en dbrecords.
De dbrecords class heeft o.a. een functie getIterator(), die een iterator geeft van een lijst met alle overeenkomende dbrecord's.

De dbrecord class heeft een constructor die een array (die rechtstreeks uit bijv mysql_fetch_assoc($result) komt) omzet naar de overeenkomstige object properties. De naamgeving van de object properties komt dus exact overeen met de naamgeving van de kolommen van de tabel. Dit is ook erg handig bij de 'UPDATE' of 'INSERT' method van de dbrecord class.

Ik raad sterk af om in je methods nogmaals de naam van de tabel terug te laten komen, omdat je daarmee veel minder makkelijk code kan schrijven die voor elke tabel werkt. En in dat laatste zit nu juist IMO het winstpotentieel van OOP.

Om te zoeken naar bepaalde personen zou je bijv kunnen doen:

PHP:

$personen = new personen;
$personen->conditions[] = 'geslacht = "m"';
$iterator =& $personen->getIterator();

conditions is default array('1);
getIterator() maakt een SQL query met implode('AND', $conditions) voert deze uit en maakt hier een iterator van.

Query wordt dus: SELECT * FROM persoon WHERE 1 AND geslacht = "m"

Hij doet overigens altijd SELECT *. Mijn ervaring is dat de snelheid niet noemenswaardig verschilt met specifieke kolomnamen noemen. Dit zou wel kunnen uitmaken als je zeer grote BLOBs oid in je db hebt en je database op een andere machine dan je webserver draait.

Ik heb hier met een succes een redelijk grote applicatie mee gebouwd, die gemakkelijk is te onderhouden en uit te breiden.

[ Voor 10% gewijzigd door Verwijderd op 04-03-2004 22:21 ]

[maartenvdv737]

Op die manier ben ik het nu inderdaad ook aan het opbouwen, ik ga nu beginnen aan een class Personen die meerdere VO's teruggeeft van personen.

Verder heb ik mijn select/insert/update/delete functies in de db class zo opgebouwd dat het mogelijk is om de class Person te extenden naar Employee en dan bij een insert van employee meteen de velden uit Person als Employee te selecteren.

Ik ben nog in dubio wat ik allemaal aan variabelen in mijn VO moet zetten, op dit moment is het zoiets:

PHP:

class Employee extends User{
    var $function;
    
    // Template
    var $template = "employee";         // Make private
    
    var $table = "Employee";            // Make private
    
    function Employee(){
        parent::User();
        
        $this->tables[] = "Employee";
        $this->table_fields[] = "function";
    }
}

als php 5 eraan komt moet dat zoiets worden:

PHP:

class Employee extends User{
    $function;
    
    // Template
    protected $template = "employee";           
    
    private $table = "Employee"; 
                
    function __construct(){
        parent::_construct();
        
        $this->tables[] = $table;
        $this->table_fields[] = "function";
    }
}

[Verwijderd]

Wat stelt de 'user' class voor?
Ik raad je af om een inheritance hierarchie te gebruiken in combinatie met een database.

Een relationele database is gebaseerd op tabellen, en heeft een platte structuur. Hier proberen een class hierarchie overheen te leggen is zeer moeilijk. Als je toch zoiets wilt proberen, lees dan http://www.agiledata.org/essays/impedanceMismatch.html , dan weet je waar je aan begint... (edit: betere link: http://www.agiledata.org/essays/mappingObjects.html )

Mijn ervaring: als je twee afwijkende werelden (in dit geval OO en relationeel) wilt combineren, kun je alleen de overeenkomende eigenschappen gebruiken. Eigenschappen waar dus tussen beide werelden een 1 op 1 relatie bestaat.

Bijv
class persoon <-> tabel 'persoon'
persoon object <-> rij uit tabel persoon
object property <-> veld van een bepaalde rij

Als je probeert eigenschappen te gebruiken die niet voorkomen in 1 van beide werelden, moet je ingewikkelde code schrijven. In dat geval kan je denk ik beter eens gaan kijken naar Object-Relational frameworks, waarvan er in Java bijv zeer veel geschreven zijn.

Handig truukje: met get_class($this) kan je in je base class verwijzen naar de classnaam van het object. Zo hoef je dus niet 2x de term 'employee' te gebruiken.

[ Voor 10% gewijzigd door Verwijderd op 05-03-2004 14:19 ]

[Verwijderd]

Tegen dit 'probleem' ben ik ook aangelopen.
Als je een hele lijst met personen nodig hebt is het slecht voor de performance om bij het aanmaken van elk Persoon object in de lijst een select query uit te voeren.
Ik heb dan ook een PersonenHome object gemaakt (of PersonenManager)
Hierin zit de select voor het selecteren van een hele lijst.
Die lijst lees ik uit en per record maak ik dan een persoon object met de inhoud van een record.
Deze gaan in een lijst die als return dient.
Je dient dan een object te maken van Persoon dat zowel een record als een id accepteert. Krijg je het hele record heb je de gegevens, krijg je het ID dan kun je middels een select alles uit de database halen.

Op deze manier kun je met objecten werken zonder dat je de database om zeep helpt met onnodig veel selects.

Ik programmeer ook nog wel eens het een en ander in Java en bij het gebruik van java beans kom je deze object en home constructie ook nogal eens tegen.

[ Voor 10% gewijzigd door Verwijderd op 05-03-2004 13:59 ]

[maartenvdv737]

Ik heb die artikelen gelezen en ik denk dat ik er redelijk aan het uitkomen ben.

Een probleem wat ik nu heb is dat de scope van mijn classen niet goed lijkt te zijn. PHP 4 heeft geen ondersteuning voor private en protected.

PHP:

class Person{
  var $id,$name;
}

class Employee extends Person{
  var $salary;
}

$employee = new Employee();
$person = new Person();

print_r(get_class_vars(get_class($employee)));

output:
Array
(
[id] =>
[name] =>
[salary] =>
)

Dit moet ik nou net niet hebben, omdat mijn tabellen hierarchisch georganiseerd zijn wil ik het volgende resultaat bereiken:

get_class_vars(get_class($person) : --> id,name
get_class_vars(get_class($employee) : --> salary

Ik heb wel een oplossing, maar die is niet zo netjes, omdat ik zo extra variabelen moet toevoegen aan mijn VO classen.

PHP:

class Person{
  var $id,$name;
  var $table_fields = array("id","name");
}

class Employee extends Person{
  var $salary;
  var $table_fields = array("salary");
}

$person = new Person();
$employee = new Employee();

print_r($person->table_fields);
print_r($employee->table_fields);

Echter, mijn structuur werkt zo dat ik de $employee instantie aan een update functie voer, die hem op elk niveau van de hierarchie gaat updaten.

DUS: $employee gaat door de update van de class EmployeeDAO maar ook door de update van de class PersonDAO.

In beide gevallen geeft $employee->table_fields de velden van $employee.

Weet iemand hoe ik dit kan bereiken zonder te veel aan de structuur te wijzigen?
Weet iemand of dit in php 5 wel bereikt kan worden? Niet dat we daar nu veel aan hebben.

[ Voor 35% gewijzigd door maartenvdv737 op 06-03-2004 23:02 ]

[Verwijderd]

Ik denk dat de beste oplossing dan is je te beperken tot een properties array voor elk VO.

PHP:

class person {
  var $properties = array('id'=>0,'name'=>'');
}

Deze kun je in de employee class overriden:

PHP:

class employee extends person {
  var $properties = array('salary'=>0);
}

De veldnamen kun je vinden door te doen:

PHP:

$person = new person;
print_r(array_keys($person->properties));

[ Voor 8% gewijzigd door Verwijderd op 07-03-2004 00:20 ]

[maartenvdv737]

Ik heb het nu inderdaad voor elkaar op de bovenstaande manier.

Nu zit ik nog met 1 probleem. Elke class van de hierarchie heeft nu update/select/delete/insert methodes. Ik heb die echter zo ontworpen, dat ze voor elke class hetzelfde zijn.

Ik wil ze dus eigenlijk in de laagste class van de hierarchie zetten, zodat elke class de functies kan gebruiken. ECHTER, ik krijg een foutmelding dat mijn laagste class geen parent heeft, wat klopt natuurlijk:

PHP:

function _delete(&$vo) {   
   
 $tr = new Transaction();
 $tr->addQuery("DELETE FROM " . get_class($vo) . " WHERE id = " . $vo->id);
     
 $this->db->delete($tr);
     
 $parent_vo = $this->parent_vo($vo);
 parent::_delete($parent_vo);

   }

Met de parent::_delete($parent_vo) ga ik de volgende class in de hierarchie updaten. Zet ik dit echter in mijn laagste class, die dus als eerste ge-extend wordt, dan krijg ik de foutmelding:

Fatal error: No parent class available in


Is daar iets op te verzinnen?

[Verwijderd]

Zoiets?

PHP:

if(get_class($vo) != 'naamvanbaseclass') {
  $parent_vo = $this->parent_vo($vo);
  parent::_delete($parent_vo); 
}

[maartenvdv737]

Ik heb de volgende structuur:

DAO --> Person --> User --> Employee

Person, User en Employee hebben nu alle 3 dezelfde functie _delete() die een row verwijderd.
User en Employee roepen de delete van de parent aan, Person niet, omdat DAO geen _delete class heeft.


Omdat deze functies practisch hetzelfde zijn, wil ik ze in de laagste class zetten, zodat ik ze niet in elke volgende class in de hierarchie opnieuw hoef te implementeren.

Haal ik echter _delete weg uit Person/User/Employee en zet ik hem in DAO, dan krijg ik de error: Fatal error: No parent class available

Mijn functie delete ziet er alsvolgt uit:

PHP:

function _delete(&$vo) {   
  $this->db->delete($vo);
     
  if(get_class($vo) != 'Person') {
     $parent_vo = parent::get_vo($vo);
     parent::_delete($parent_vo);
  } else {
     $vo->id = 0;
  }
}

Het lijkt erop dat het gewoon niet kan, hij evalueert blijkbaar eerst de hele class en ziet dan dat er ergens om een parent:: gevraagd wordt, ook al gebruikt DAO die nooit.

[ Voor 6% gewijzigd door maartenvdv737 op 07-03-2004 17:24 ]