OO: Implementatie database denkwijze
Ik zit een beetje te twijfelen over hoe ik mijn classes ga maken,
en wil nu graag aan jullie vragen hoe je het doet.
Namelijk voor veel classes heb je een verbinding met de database nodig,
Maar hoe geef je die mee?
Ik heb bij veel classes van andere gezien dat ze dat bij de construct meegaven, maar dat vind ik niet zo netjes.
Want dan moet je dat bij elke class meegeven die een db verbinding nodig heeft.
Maken jullie dan gewoon een aparte class voor de db verbinding en instantieren jullie die in de construct?
Ik hoor het graag!
Gewijzigd op 03/10/2011 20:03:11 door Niels K
Victor - op 30/09/2011 14:49:46:
...
Ik heb bij veel classes van andere gezien dat ze dat bij de construct meegaven, maar dat vind ik niet zo netjes.
Want dan moet je dat bij elke class meegeven die een db verbinding nodig heeft.
Maken jullie dan gewoon een aparte class voor de db verbinding en instantieren jullie die in de construct?
Ik hoor het graag!
Ik heb bij veel classes van andere gezien dat ze dat bij de construct meegaven, maar dat vind ik niet zo netjes.
Want dan moet je dat bij elke class meegeven die een db verbinding nodig heeft.
Maken jullie dan gewoon een aparte class voor de db verbinding en instantieren jullie die in de construct?
Ik hoor het graag!
ja ik heb een aparte db class, ik zet hem altijd in de construct van andere classes maar heb wel een connect methode in de dbclass.
want dan kan je alle opties/functies gebruiken van de parent class
dan word de class die je aanmaakt de child van de database class.
Victor - op 30/09/2011 15:57:03:
@Marco is dit dan niet in tegenstrijding van de denkwijze van OOP?
Nee dat is het principe van OOP. Je maakt een basis class met een aantal basis functies, door een functie opnieuw te definieren in de extended class overschrijf je ze(php is daarin heel simpel).
However:
Wat Marco voorstelt is natuurlijk niet zo slim: een dbclass connect naar een database, en sommige andere classes hebben dat niet nodig.
want als hij enkel zijn database connectie nodig heeft kan hij die heel makkelijk gebruiken als hij de classes waarin hij die nodig heeft eventueel extend.
En ja het is waar dat als je in de child class een functie opnieuw maakt dat hij hem dan overschrijft.. maar ik ging er even vanuit dat hij een database class heeft en daarnaast een class met zijn help/standaard functies heeft...
Marco PHPJunkie op 30/09/2011 16:13:33:
@ger kan je me misschien uitleggen waarom dat niet zo slim is ?
Omdat inheritance (php extends) betekent dat alle functies die daarin gedefinieerd zijn mee worden overgenomen. Misschien ben ik ook ook wel een beetje adhoc geweest maar één van de eerste regels met programeren is: vraag nooit onnodige resources aan.
Gewijzigd op 30/09/2011 16:25:04 door Ger van Steenderen
Oke true dat is zeker waar en daar ben ik het hellemaal mee eens (gebruik nooit overbodige resources / code aan)
maar als hij enkel en alleen een class heeft voor zijn database verbinding/afhandelingen en hij heeft ze in die andere class echt nodig kan je het heel goed gebruiken niks mis mee....
En anders als er teveel functies in staan die je niet nodig hebt kan je het is het beter om (zoals Ger al zei) hem in de construct te zetten...
Gewijzigd op 30/09/2011 16:50:28 door Marco PHPJunky
lol, dat we het toch nog ergens over eens zijn.
maar zonder gekheid: als je OOP wilt gaan werken, bouw je een base class waarin je een hoop functionaliteit zet die je later altijd kunt terug gebruiken. dus wellicht ook de optie om naat een datbase te connecten
XD dan zijn we het daar ook over eens :P
nog iets waar we het over eens zijn dus XD
maar het kan ook komen dat ik persoonlijk altijd een database class (enventueel voor meerdere databases (mysql, mssql, sqlite/3)) heb en een functies class en daarnaast de modules vandaar maby ook mijn reactie en antwoord.
Gewijzigd op 30/09/2011 17:24:16 door Marco PHPJunky
Code (php)
Je hebt dan een mooie scheiding van verantwoordelijkheden (het model houdt zich niet met de DB bezig) en je bent veel flexibeler (je kan altijd een uitgebreide versie van Database meegeven en zo functionaliteit toevoegen/aanpassen.
Het gebruiken van een universele super-class wordt vaak gezien als een slechte gewoonte, omdat je dan (vaak) taken niet goed scheidt.
Het is prima om de het DB object in een statisch veld in een superclass te stoppen, maar niet om je model een DB klasse uit te laten breiden (en dan heb ik het niet over active records en verwanten, maar over de DB connectie zelf).
Ozzie PHP op 02/10/2011 23:47:46:
Ik snap niet helemaal wat je bedoelt Pim. Ik bedoel dat je het model zou extenden met een General Model en dat General Model maakt gebruik van een database class. Aan het General Model geef je dan in de construct de database class mee. Snap je wat ik bedoel?
Juist. Precies! Je maakt gebruik van een database class, maar het is niet een database class. En daarom erf je niet over.
Hou je objecten zo klein mogelijk, zo specifiek mogelijk, zodat je ze gemakkelijk kan verbeteren, testen en vervangen. Juist dan merk je de voordelen van object georiënteerd programmeren.
Ik snap niet helemaal wat je bedoelt met "Je maakt gebruik van een database class, maar het is niet een database class. En daarom erf je niet over."
Als je in ieder Model gebruik maakt van een database dan kun je:
a) aan ieder model de database meegeven: new Model(new Database)
b) ieder model extenden met een General Model waarin standaard een database verbinding aanweig is (evenals nog een aantal andere basisfunctionaliteiten)
Volgens jou is manier A beter, maar ik zou dan graag weten waarom dat precies is (graag in Jip en Janneke taal) zodat ik er zelf straks ook m'n voordeel mee kan doen. Bedankt alvast voor je antwoord!
Verder vind ik de discussie echt heel interessant en er zaten dus blijkbaar nog meer mensen mee te rommelen:p
Ook kan je je model laten beschikken over een PDO object, door het een property ($this->pdo) te laten zijn. Dan is je model klasse veel simpeler en flexibeler.
Daarna moet je nog gaan bedenken hoe je precies je modellen aan je DB gaat vlechten. Hier zijn verschillende recepten voor en dan wordt het pas echt leuk ;).
Wat ik in gedachten heb is (ongeveer) dit.
1) Een aparte database class die de PDO class extend. Waarom een aparte database class? Omdat ik daar voor mezelf wat handigheidjes in wil stoppen zoals bijvoorbeeld chaining, $database->select('veld')->from('tabel')->run();
2) Een General Model met een aantal standaard functionaliteiten. In dit model wordt (eenmalig) een database connectie opgezet en wordt de databse class uit punt 1 ingesteld als property, $this->database.
3) Ieder afzonderlikj model laat je extenden met het General Model uit stap 2. Hierdoor heb je dus in ieder model de beschikking over een database verbinding via $this->database.
Is dit niet een goede manier? Het voordeel is dat je niet aan ieder model een database verbinding hoeft mee te geven.
Of zet je zoiets dan in een registry class? En als je niet de database verbinding in je construct van je GM regelt, moet je hem alsnog zelf aanmaken.