Abstracte data layer

De interface IDB wordt precies 1 keer gebruikt (implements alleen is natuurlijk onzin). Dan lijkt me de interface een beetje overbodig, denk je niet?
Een interface is pas zinnig als er getypecast wordt. Dat wordt 1 keer gedaan.

Daarnaast snap ik het voordeel niet van dit package. Uiteindelijk draait het toch om wat het snelst is, is het niet? Dit is niet het snelst. En -maar dat is persoonlijk- het is ook niet uitermate makkelijk ofzo... Vooral de querydb::prepare functie niet. En dan querydb::execute() met een array columns? Is dat makkelijk? Vind van niet.

Misschien kan je een mooi geavanceerd voorbeeld maken van wanneer het wel makkelijk is, deze package.

Die interface is voor het abstraheren van je database. Of je nu postgresql, mysql, oracle of access gebruikt, de interface blijft hetzelfde. Hierdoor hoef je niet heel je applicatie om te bouwen als je over wil stappen van database, maar hoef je alleen een nieuwe layer te maken ( voor je nieuwe database ).

Wat betreft snelheid, daar heb je deels gelijk in. Tuurlijk is snelheid belangrijk, maar overzichtelijk/orde/uitbreidbaarheid misschien meer. Object georienteerd programmeren is vaak niet sneller, maar het geeft je een goed beeld over wat je aan het doen bent en is veel makkelijker uit te breiden en te begrijpen.

En die kolommen hoeft je niet in een array te stoppen als je dat niet wilt. Je kan ze ook gewoon in de sql string zetten.
Het makkelijke hieraan is dat je vrij weinig hoeft te doen aan escapen en toevoegen van quotes. Je geeft gewoon mee welke waarden je wilt gebruiken en wat voor type deze waarde heeft, en execute regelt de rest.

Ik heb het voorbeeld aangepast, nu zie je wat beter wat het doet. Het vorige voorbeeld wat niet zo goed moet ik toegeven.

Ik heb eerder een vergelijkbaar setje klassen geplaatst, ook met de features die jij hebt + een paar meer.

Maar je code ziet er naar mijn idee een stuk overzichtelijker uit dan die van mij :)

Nog een kleinigheidje: je hebt Iterator geïmplementeerd, en ook een seek-method. Je zou ook SeekableIterator kunnen implementeren dus.

Fijn om weer eens wat echte scripts op PHPhulp te zien!

Stien, een interface heeft geen zin als je niet type hint. Dat doe je 1 keer. De interface zal je nooit meer zien. Het is zelfs irritant dat je in elke class nu precies dezelfde functies moet gebruiken (je kan in Strict mode nooit een extra parameter meegeven aan een SQLite class (1 meer dan bijv de MySQL variant)).
Het is leuk om een blauwdruk te hebben van je class, maar zet het dan gewoon in comments ofzo :S Een interface voegt zo weinig toe. Nja 1 keer dus.
Die kolommen in array is opzich wel handig ja :) Maar het is in een beetje vreemde vorm gegoten (vind ik) met dat prepare en stored_procedure enzo...

Hoe dan ook. Het is een mooi voorbeeld van PHP5 OO, maar ik vind m iets te. En die van Jelmer is zeker te. Dat gaat echt te ver :D Luilak!

Ik? Een luilak? Ik heb dat hele script uit mijn duim gezogen, en ik ben een luilak? Enig idee hoe lang ik de stofzuiger op mijn duim moest houden?

Maar even serieus: Reacties zijn om te informeren, overreden doen wij in het forum (is zelfs een aparte categorie voor!) De interface is wel handig waneer je een andere database-api (SQLite, Postgre, MySQLi) wilt gaan ondersteunen. Alleen zijn al die 4 functies voor het 'fetchen' van data dan een beetje ongelukkig, aangezien die niet alle vier door alle databases ondersteund (zouden moeten) worden. Dus die interface kan naar mijn idee niet echt kwaad.

Maar als we daar al op gaan miereneuken, dan bewijst dat toch even dat dit op zich best een goed script is!

... alleen zou ik toch echt mijn Data Objecten erg gaan missen. Eenmaal eraan gewend, wil je niet meer anders :+

Je zou trouwens ook wat typwerk in je Exceptions kunnen weglaten door get_class() etc eruit te gooien. Volgens mij zitten die al in de standaard implementatie van Exception, en anders zijn ze wel te achterhalen via de backtrace.