Ik heb een vraag voor de ervaren (PHP-)programmeur.

Ik heb een website waarvan de achterkant is opgezet in PHP en MySQL. Opzet is op zich vrij eenvoudig en is OOP geprogrammeerd. Alles werkt, maar ik wil het een keer opnieuw gaan maken en deze keer beter natuurlijk.

Echter, telkens weer loop ik tegen dezelfde vraag aan. Waarschijnlijk is het een zeer basic ding maar ik kom er zelf niet uit. Mocht toelichting teveel werk zijn dan is een link naar een geschikt artikel op internet ook prima.

Hier komt het:

Het betreft een website m.b.t. beleggen/aandelen. Ik zal hier een vereenvoudigd voorbeeld noemen om mijn vraag te verduidelijken.

Ik heb 3 classes:

Aandeel, Beurs, AgendaItem

class Aandeel heeft o.a. de volgende variabelen en functies:
id
isin-code
naam
getID()
setID(...)
getIsinCode()
setIsinCode(...)
getNaam()
setNaam(...)

class Aandeel is uitsluitend verantwoordelijk voor Aandelen dus de database-queries (select, insert, update, etc) die hierin staan gaan alleen over de table 'Aandeel' in de database.

Hetzelfde geldt voor de andere 2 classes Beurs en AgendaItem.

Maar het probleem is nu dat je niet altijd uit de voeten kunt met queries op slechts één tabel. Je wilt natuurlijk kunnen joinen en veel meer. Bijvoorbeeld: 'geef me alle aandelen van beurs AEX die een AgendaItem hebben binnen nu en twee weken'.

Maar hoe zet je nu nette code op, waarbij je OOP werkt en toch geavanceerde queries etc. kunt toepassen? Ik heb zelf het idee dat ik een tussenstap mis o.i.d.

Ik zou eventueel ook heel erg geholpen zijn met een PHP script met eenvoudige opzet dat ik eens door kan 'worstelen'.

Overigens gebruik ik voor database toegang een abstractielaag (PEAR of AdoDB) maar dat maakt denk ik voor de vraag niets uit.

dit heeft in principe niets met classes te maken, maar meer met database query's.

Hoe je dit straks graat vertalen naar een class is net hoe je het zelf aanpakt...

Als ik jou was zou ik alles in een class stoppen. Eventueel kan je een aantal functies in een apart bestand plaatsen die de algemene class extend. Maar goed, je moet goed bedenken hoe je wilt hebben en hoe je het gaat aanpakken, dat is het lastige van OOP.

Eventueel kan je een functie maken die gegevens over een aandeel ophaalt, een functie die bij de aandeel #ID de beurs opzoekt, een functie die de agenda item opzoekt en een functie die deze drie functies combineert.

Ik denk dat het met beide niet echt per se iets te maken heeft. De queries zijn geen probleem voor me.

Ik wil juist OOP gebruiken om zaken strict gescheiden te houden. Dus wil ik iets van een Aandeel weten dat vraag ik het aan een instance (of class) van Aandeel. Wil ik iets van een Beurs weten dan vraag ik dat aan een instance (of class) van Beurs.

Maar soms kan ik het niet scheiden en heeft het raakvlakken met meerdere objecten.

OOP is lastig, ga na in je ontwerp na welke stukken codes je vaker nodig hebt en verzin hier iets op. Het ontwerp is lastig, maar als je echt hulp wilt kan je beter naar PHP foras als sitemasters.be of phpfreakz.nl gaan.

De object-methodes die de queries 'wrappen' gewoon opzetten per query 'type'. Je kunt je method parameters/argumenten mee laten geven, die valideren en je query uitvoeren? Of dat nou een single SELECT of een JOIN dat maakt toch niet uit? Je logica gewoon binnen de method uitwerken, opdelen in kleine stukjes.

Bedankt voor de reacties. Ik merk dat ik niet zo goed onder woorden kan brengen wat ik bedoel.

Ik ga eens even wat artikelen lezen op phpfreakz.nl. Mocht het me dan nog niet duidelijk zijn dan kom ik er nog even op terug.

Als je het helemaal goed aan wilt pakken en database wilt scheiden van code zou je nog eens kunnen overwegen om mysql stored procedures te gaan gebruiken. Is wel iets ingewikkelder dan queries vanuit je code te draaien maar je houdt dan wel je code gescheiden van de database. Nog een nadeel aan het gebruik van stored procedures is, is dat oudere versies van mysql server dit niet ondersteunen.

Ik denk niet dat stored procedures in deze mijn probleem oplossen. Het is ook niet zo dat de queries die ik gebruik heel ingewikkeld zijn; ik kan het allemaal af met standaard SQL (volgens mij ook een eis als je met een abstractie-laag werkt zoals AdoDB).

Ik heb ooit eens dit artikel gelezen. Een deel daarvan is me zeer nuttig gebleken maar ook daar beschrijft hij een stricte scheiding tussen de verschillende objecten. En natuurlijk kan ik via PHP ook een join simuleren maar dat zou wel heel inefficient zijn.

Nee wat je zegt is niet helemaal juist. Een abstractie laag (ado) vereist niet dat je met queries uit je code werkt. Wat je doet is een query over de db connectie versturen naar je mysql server, of dit nou een select query is of CALL storedprocedure_naam dat maakt niet uit. Ik denk dat je eens informatie over het Three-tier(N-Tier) architectuur moet zoeken. Waar je DAL(Data access layer) BLL(Business Logic Layer) en de presentatie laag apart hebt. Soort van MVC(Model View Controller).

Bedankt voor de tip over n-tier.

Wat betreft de abstractie-laag. Het moet (theoretisch?) mogelijk zijn om dmv bijv. AdoDB te switchen van bijvoorbeeld MySQL naar Oracle DB of Postgres of welke ondersteunde database dan ook. Lijkt me dat je dan geen MySQL-specifieke functionaliteit wilt/kunt gebruiken.

Geen probleem, daarvoor is het forum he. Nee je bent denk ik in de war met PDO. PDO is een php extensie die probeerd om de connectielaag die voor elke database nodig is uniform te maken door middel van een interface. Voor elke database zul je wel de juiste pdo moeten inladen anders werkt het niet. Queries schrijven zul je echter zelf moeten blijven doen, aangezien mysql, sql server en oracle hun eigen syntax hiervoor gebruiken. Je zult dus dan zeker nog specifieke functionaliteit voor de gebruikte database kunnen/willen gebruiken. Uiteraard kun je zelf nog een soort van DAl schrijven waar je voor bv mysql en sql server 2 queries bouwt met dezelfde functionaliteit en vanuit de BLL roep je deze querie aan door middel van een methode. Deze methode roept dan weer de gekoppelde DAL functie aan en geeft eventueel de juiste params door. Op basis van een variabele die je dan in je Application Config bestand hebt staan of waar dan ook of op basis van het meesturen van een param waarin je opgeeft welke db je wilt gebruiken zou je kunnen switchen tussen queries.

Origineel gepost door MDP

Geen probleem, daarvoor is het forum he. Nee je bent denk ik in de war met PDO. PDO is een php extensie die probeerd om de connectielaag die voor elke database nodig is uniform te maken door middel van een interface. Voor elke database zul je wel de juiste pdo moeten inladen anders werkt het niet. Queries schrijven zul je echter zelf moeten blijven doen, aangezien mysql, sql server en oracle hun eigen syntax hiervoor gebruiken. Je zult dus dan zeker nog specifieke functionaliteit voor de gebruikte database kunnen/willen gebruiken. Uiteraard kun je zelf nog een soort van DAl schrijven waar je voor bv mysql en sql server 2 queries bouwt met dezelfde functionaliteit en vanuit de BLL roep je deze querie aan door middel van een methode. Deze methode roept dan weer de gekoppelde DAL functie aan en geeft eventueel de juiste params door. Op basis van een variabele die je dan in je Application Config bestand hebt staan of waar dan ook of op basis van het meesturen van een param waarin je opgeeft welke db je wilt gebruiken zou je kunnen switchen tussen queries.

Nu raak ik in de war. Ik was er toch van overtuigd dat PEAR MDB2 en AdoDB juist ervoor bedoeld zijn om met generieke queries, alle ondersteunde databases te kunnen benaderen. Dus als ik nu bijvoorbeeld MySQL gebruik als database maar straks toch op Oracle over moet gaan, dat ik dan slechts de 'driver' hoef aan te passen (waarschijnlijk één configuratie-regel in de abstractie-laag) en dat alles dan blijft werken, zonder aanpassing van de queries?