[PHP] Geschikte manier om gegevens in database benaderen

[SvMp]

Momenteel ben ik bezig met een aantal PHP-projecten, zowel hobbymatig als op mijn werk, waarbij gebruik wordt gemaakt van een database met enkele tientallen tabellen. Er staan verschillende gegevens in de database. Gegevens worden gelezen (vaak) en geschreven (minder vaak). Ik ben op zoek naar de meest geschikte manier om dat te doen vanuit de applicaties. Het gaat niet om de manier waarop de database moet worden benaderd (MySQLi vs. PDO bijvoorbeeld), maar de manier waarop de applicatie om gaat met het opvragen en opslaan van de gegevens. Dit kan rechtstreeks met de database geregeld worden, maar ook via een aantal classes die het werk doen.

Ik vind het zeer wenselijk om de communicatie met de database en de SQL-commando's slechts in een beperkte groep classes te hebben. Deze bieden eenvoudige functies aan de applicaties om de gegevens te verkrijgen. Daarnaast geeft het meer structuur en kan ik caching gemakkelijker regelen. Als ik het echter ga realiseren, loop ik tegen allerlei problemen aan en lukt het niet om classes te bedenken die SQL in de applicatie zelf overbodig maken.

Ik ben op zoek naar de beste manier om dit aan te pakken.

Waar ik tegenaanloop wil ik beschrijven aan de hand van een vereenvoudigd voorbeeld.

In de database staan gegevens over plaatsen. Andere gegevens kunnen daar naar toe verwijzen. Iedere plaats heeft een uniek ID. De informatie van een plaats is in drie tabellen te vinden:

SQL:

CREATE TABLE plaats (
   id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
    aantal_inwoners INTEGER NOT NULL,
    PRIMARY KEY (tekstnr, taal_id),
    UNIQUE KEY (tekstnr, taal_id)
);

CREATE TABLE plaatsnaam (
   id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
   plaats INTEGER UNSIGNED NOT NULL REFERENCES plaats(id),
   taal INTEGER UNSIGNED NOT NULL REFERENCES taal(id),
    naam VARCHAR(80) NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY (id),
    UNIQUE KEY (plaats, taal)
);

CREATE TABLE beschrijving (
   id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
   plaats INTEGER UNSIGNED NOT NULL REFERENCES plaats(id),
   taal INTEGER UNSIGNED NOT NULL REFERENCES taal(id),
    tekst VARCHAR(255) NOT NULL,
    PRIMARY KEY (id),
    UNIQUE KEY (id),
    UNIQUE KEY (plaats, taal)
);

Je kunt een class schrijven die met de database communiceert en gegevens van een plaats leest of wegschrijft:

PHP:

   class cPlaats {



      public $id;

      public $aantal_inwoners;

      public $namen;

      public $beschrijvingen


      function __construct($id) {
         $lees_plaats($id);
      }


      public function lees_plaats($id) {

         $this->id=$id;

         // uit database lezen

         // $namen[$taal]=$naam_in_bepaalde_taal

         // $namen[$beschrijving]=$beschrijving_in_bepaalde_taal

      }

      public function schrijf_plaats($id) {



      }



      public function naam() {

         // return naam van plaats in door applicatie gebruikte taal

      }



   }

Voor elke plaats waarvan je gegevens gebruikt, maak je een object. Dit lijkt in eerste instantie erg aantrekkelijk, zeker in een beheer-gedeelte. Maar voor het overgrote deel van applicatie is dit overkill. Meestal wil je een naam hebben van één bepaalde plaats in de door de applicatie gebruikte taal.

Ik kan er een functie aan toevoegen, plaatsnaam($plaats_id), die de naam teruggeeft. Dit kan echter niet in bovenstaande class, want een object correspondeert met één bepaalde plaats. Eventueel kun je er een static functie van maken. Ik ben daar echter geen fan van.

Dus nog maar een class:

PHP:

   class cPlaatsfuncties {

      public function plaatsnaam($plaats_id) {
         // return naam van plaats in door applicatie gebruikte taal 
      }

      public function infotekst($plaats_id, $taal) {
         // return infotekst in taal $taal
      }

   }

Dit is een aantrekkelijke oplossing. Je maakt alleen objecten als je de functies nodig hebt. Voor elke soort data (useraccounts, producten, transacties, etc...) een class.

Helaas, opnieuw problemen:
1. De class cPlaats wordt eigenlijk alleen maar gebruikt door het admin-gedeelte. Alleen daar wordt met alle mogelijke gegevens van een plaats gewerkt. De verleiding is groot om vanuit het admin-gedeelte gewoon rechtstreeks de database aan te roepen, maar dan is de SQL-code weer niet op één plek.
2. Beide classes bevatten overlappende functionaliteit. Voorbeeld: Als een plaatsnaam niet beschikbaar is in de taal van de applicatie, dan wordt de plaatsnaam genomen in de plaatselijke taal. Is die niet beschikbaar, dan Engels. Is die niet beschikbaar, dan wordt de eerste naam gepakt die in de database staat voor de plaats. De functie plaatsnaam in cPlaatsfuncties doet dat. Maar ook de functie naam in cPlaats. Ik kan natuurlijk vanuit plaats de functie plaatsnaam aanroepen in cPlaatsfuncties, maar dan worden opnieuw gegevens gelezen uit de database en dat is zonde.
3. Ik kan beide classes fuseren. lees_plaats en schrijf_plaats werken dan met arrays waar alle gegevens van één plaats in staan. Nadeel: lees_plaats en schrijf_plaats worden alleen door het admin-gedeelte gebruikt, maar maken de veel gebruikte class wel groter.
4. Er zijn enorm veel mogelijke acties op plaatsgegevens. Dit geeft vele functies. Bijvoorbeeld het zoeken van een plaats. Soms is een rijtje met namen+id's voldoende. Soms wil je in het rijtje namen alle beschikbare namen (verschillende talen), soms alleen de naam één bepaalde taal. Soms wil je alleen maar een rij id's hebben. Dit levert veel functies op, of functies met veel argumenten.
Splitsen lijkt een oplossing: een zoek-functie geeft alleen id's terug, een andere functie kan de namen er in verschillende varianten bijleveren.
Nadeel: Er worden vele afzonderlijke queries uitgevoerd voor taken, die ook in één query kunnen.
"SELECT plaats, naam FROM plaatsnaam WHERE naam LIKE ? AND taal=1" is sneller, dan "SELECT plaats FROM plaatsnaam WHERE naam LIKE ? AND taal=1", en vervolgens x maal "SELECT naam FROM plaatsnaam WHERE plaats=? AND taal=1"

Een heel verhaal, misschien wat van de hak op de tak, maar ik hoop dat de vraag waar het om gaat duidelijk genoeg is.

[nika]

Meestal wil je een naam hebben van één bepaalde plaats in de door de applicatie gebruikte taal.

dat is toch geen probleem, je class representeert to 1 rij in je dataset? Dus je hebt gewoon een methode als

code:

public function find($id){
    //find record in DB
    //populate properties
   return $this;
}

eventueel maak je die methode nog static. Kan je eenvoudig ergens cPlaats::find($id) aanroepen.

vervolgens heb je ook een methode als

code:

public function fetchAll(){
    $plaatsen = array();
    //laad alle rijen uit tabel
    foreach ($rowset as $row){
        $plaatsen[] = new cPlaats($row);
    }
    return $plaatsen;
}

[SvMp]

Die fetchAll()-method geeft juist het probleem van overhead. Alles wordt ingelezen, terwijl je wellicht alleen maar de naam + aantal inwoners wil hebben.

[X-Lars]

Wellicht een goed idee om eens in te lezen in ORM (bijv. Propel of Doctrine).

Daarnaast zie ik wel veel winst in het gebruik van views in je db, die zouden wel een deel van je problemen op lossen (m.n. overlappende functionaliteit).

[nika]

SvMp schreef op donderdag 30 september 2010 @ 16:41:
Die fetchAll()-method geeft juist het probleem van overhead. Alles wordt ingelezen, terwijl je wellicht alleen maar de naam + aantal inwoners wil hebben.

Maar die methode hoef je toch niet aan te roepen als ie niet nodig is. Dan roep je gewoon de find() methode aan. Of iets als findByPlaatsNaam($naam), welke 1 object met alleen de gegevens van de betreffende plaats teruggeeft.

[nika]

X-Lars schreef op donderdag 30 september 2010 @ 19:27:
Wellicht een goed idee om eens in te lezen in ORM (bijv. Propel of Doctrine).

Daarnaast zie ik wel veel winst in het gebruik van views in je db, die zouden wel een deel van je problemen op lossen (m.n. overlappende functionaliteit).

Views zijn naar mijn idee not done. Ze implementeren business logic in de data layer. Lastig te onderhouden.

Edit: alhoewel ik best begrijp dat het voor kleinere projecten handig kan zijn hoor.

[ Voor 8% gewijzigd door nika op 30-09-2010 20:24 ]

[Kajel]

Ik kan alleen maar onderschrijven wat X-Lars zegt! Ga eens op onderzoek uit in de wondere wereld van ORM. Wat jij omschrijft, is namelijk precies wat ORM doet. Ik gebruik voor mijn werk het framework Symfony, waarbij we gebruikmaken van Doctrine voor de Model-layer, en dat bevalt heel goed. Ik ben blij dat ik 90% van de tijd geen regel SQL meer hoef te schrijven! Omgaan met data als objecten is - zeker in PHP5 - eigenlijk een heel natuurlijke gang van zaken.

[Hydra]

nika schreef op donderdag 30 september 2010 @ 20:24:
Views zijn naar mijn idee not done. Ze implementeren business logic in de data layer. Lastig te onderhouden.

Euh, nee? Een view geeft duidelijk aan wat het is, het is een 'view' op het datamodel. Als twee verschillende applicaties 1 tabel benaderen, richt je voor beiden een view in zodat ze de data zien zoals ze die data nodig hebben. Dat heeft niks met business logic te maken. Natuurlijk kun je business logic in views of stored procs gaan proppen, maar da's een typische Oracle DBA oplossing.

Het voordeel van een view is dat je de tabel loskoppelt van de applicatie. Dus als een tabelstructuur wijzigd (dus als een kolom opeens anders heet ofzo), dan kun je gewoon de view daarop aanpassen en hoeft de applicatie niet aangepast te worden.

[cytherea]

Een ORM zoals Doctrine of Propel is zeker een mooie oplossing. Alleen kan het niet eenvoudig zijn om te implementeren en te leren. Hoewel dat natuurlijk wel een goeie investering is omdat het veel tijdwinst op kan leveren.

Alleen bij het verwerken van grote datasets wordt het gebruik van een ORM laag meer een last dan een zegen (weet ik uit ervaring). Een ORM is niet in staat om goeie JOIN queries te maken wat ook wel logisch is omdat hij vaak niet vantevoren weet welke data je gaat gebruiken enzo.

[nika]

Hydra schreef op maandag 04 oktober 2010 @ 15:11:
[...]
Het voordeel van een view is dat je de tabel loskoppelt van de applicatie. Dus als een tabelstructuur wijzigd (dus als een kolom opeens anders heet ofzo), dan kun je gewoon de view daarop aanpassen en hoeft de applicatie niet aangepast te worden.

Daar heb je toch je datamapper voor?

Misschien was m'n business logic opmerking wat kort door de bocht. Maar volgens mij ligt dat gevaar op de loer als je gaat werken met views en stored procedures.

Bouw je bovendien niet een extra layer in (applicatie haalt gegevens uit view, view haalt gegevens uit table)? Heb je geen performance issues dan? Weet niet precies hoe views werken in bijvoorbeeld MySql of SQLserver.

[ Voor 16% gewijzigd door nika op 05-10-2010 09:12 ]

[SvMp]

Dank voor alle reacties.

Ik heb mij wat ingelezen in ORM. Metname Propel, die heldere documentatie heeft.

Ik heb het idee dat er wel de nodige overhead is. Ik moet zeggen dat ik er niet heel enthousiast over ben. Wel biedt de documentatie ideeën om zelf geschikte objecten te schrijven om mijn data te benaderen. Want de SQL overal en nergens in de code vind ik niet kunnen.

[Hydra]

nika schreef op dinsdag 05 oktober 2010 @ 09:10:
Daar heb je toch je datamapper voor?

De ORM configuratie (bijvoorbeeld de Hibernate mapping XML files) worden over het algemeen door een developer onderhouden, de database door een DBA. Als een DBA een wijziging maakt in een tabel kan hij zonder problemen de view aanpassen. Je wil niet dat een DBA opeens in je Hibernate config moet gaan frutten.

[Kettrick]

SvMp schreef op dinsdag 05 oktober 2010 @ 11:42:
Dank voor alle reacties.

Ik heb mij wat ingelezen in ORM. Metname Propel, die heldere documentatie heeft.

Ik heb het idee dat er wel de nodige overhead is. Ik moet zeggen dat ik er niet heel enthousiast over ben. Wel biedt de documentatie ideeën om zelf geschikte objecten te schrijven om mijn data te benaderen. Want de SQL overal en nergens in de code vind ik niet kunnen.

Ik ben benieuwd wat je argumenten tegen de ORM's zijn, wat is er mis mee waar je niet enthousiast van wordt? .

Een typische eigen oplossing zal op lange termijn steeds meer naar een ORM groeien, dus tenzij je echte weloverwogen redenen hebt om een bekend stabiel stuk software niet te gebruiken zou ik het niet zelf gaan bouwen .

Misschien lijken dingen nu wat onhandig, maar zodra je een ORM gebruikt zal je zien dat de meeste vrij logisch in elkaar zitten.

[BlackHawkDesign]

Ik zie dat je het schrijven en lezen in de plaats class zelf stopt. Waarom maak je plaats niet een simpele data container. Vervolgens maak je een database class. Deze zorgt voor het uitvoeren van de queries.. en geeft dat de benodige plaats objecten terug. Vervolgens kan je dan ook een save methode in je data container stoppen.. die vervolgens je database class aanroept.

Daarna kan je er zoals velen al voorstellen er voor kiezen om die database class te vervangen voor een ORM systeem. Tegen die tijd zie je ook der voordelen van een ORM in.

dus het ziet er zo uit :

PHP:

class Plaats{
  $public id
  $public name
  .. 
  public function Save(){
  $db = new Database();
  $db->savePlaats(this);
 }
}

class Database{

public function GetPlaatsByID($plaatsID){
 ...
 // geeft een plaats object terug
}

public function SavePlaats($plaats){
 .. 
}

}

[ Voor 7% gewijzigd door BlackHawkDesign op 05-10-2010 13:20 ]

[TJHeuvel]

Dat klinkt wel als een god-class, die Database class wordt uiteraard gigantisch groot bij een redelijk project.

Waarom zou het ophalen/opslaan niet in dezelfde klasse horen?

[Hydra]

CyCloneNL schreef op dinsdag 05 oktober 2010 @ 13:21:
Dat klinkt wel als een god-class, die Database class wordt uiteraard gigantisch groot bij een redelijk project.

Waarom zou het ophalen/opslaan niet in dezelfde klasse horen?

M.i. wil je geen SQL queries e.d. in je classes verstoppen. Dat is ook een van de voordelen van een ORM systeem als Hibernate, dan zit dat netjes geconfigureerd in XML bestanden.

[nika]

CyCloneNL schreef op dinsdag 05 oktober 2010 @ 13:21:
Dat klinkt wel als een god-class, die Database class wordt uiteraard gigantisch groot bij een redelijk project.

Waarom zou het ophalen/opslaan niet in dezelfde klasse horen?

Ik zie niet in hoe die nu een god-class zou vormen. Het is volgens mij een voorbeeld van een model - datamapper - gateway implementatie (a la Zend Framework).

het model representeert data in object vorm, los van een specifieke database/tabel
de gateway is je connectie met de database (alleen generic code)
de datamapper als "vertaal slag" tussen model en gateway.

[SvMp]

Er zal idd een God-class / monster-class ontstaan als je functies voor alle tabellen in één class samen brengt, ook al is het een bepaalde categorie functies. De class wordt flink groot als je een stuk of 20 verschillende data-objecten hebt. Daarom zou ik er voor kiezen om per data-object (plaats, klant, product, foto, etc..) een class te maken die alles met dat soort data kan. In situaties waarbij door gewone gebruikers de data alleen wordt gelezen, splits ik de class op in een algemeen gebruikte versie en een admin-versie waar alle schrijf-functies in zitten.

Kettrick schreef op dinsdag 05 oktober 2010 @ 11:49:
[...]


Ik ben benieuwd wat je argumenten tegen de ORM's zijn, wat is er mis mee waar je niet enthousiast van wordt? .

Een typische eigen oplossing zal op lange termijn steeds meer naar een ORM groeien, dus tenzij je echte weloverwogen redenen hebt om een bekend stabiel stuk software niet te gebruiken zou ik het niet zelf gaan bouwen .

Misschien lijken dingen nu wat onhandig, maar zodra je een ORM gebruikt zal je zien dat de meeste vrij logisch in elkaar zitten.

Ik ben het met je eens dat ORM's logisch in elkaar zitten. Dat is ook niet te reden dat ik er niet enthousiast over ben.
Een query uitvoeren kan niet met één simpele functie, maar een aantal functies die samen een query zullen uitvoeren. Het oogt als een abstractie van SQL. Om in een simpele functie-aanroep een plaatsnaam te krijgen zoals in het voorbeeld in mijn openingspost, moet ik ook met gebruik van ORM nog een functie schrijven die de juiste plaatsnaam ophaalt. Op die manier vormt ORM een extra laag, die niet nodig is als je data benadert via eenvoudige functies. Die functies zitten afgezonderd in een verzameling classes, een prima plek om alle SQL te concentreren. Het enige wat ORM dan toevoegt is dat ik vanuit die classes wel heel makkelijk de database kan lezen, maar ik heb een class voor een MySQL-database gemaakt waarmee het gebruik van SQL ook al heel simpel is geworden.

[ Voor 56% gewijzigd door SvMp op 05-10-2010 16:39 ]

[Hydra]

[b][message=34801291,noline]SvMp schreef op dinsdag 05 oktober 2010 @
Ik ben het met je eens dat ORM's logisch in elkaar zitten. Dat is ook niet te reden dat ik er niet enthousiast over ben.
Een query uitvoeren kan niet met één simpele functie, maar een aantal functies die samen een query zullen uitvoeren. Het oogt als een abstractie van SQL. Om in een simpele functie-aanroep een plaatsnaam te krijgen zoals in het voorbeeld in mijn openingspost, moet ik ook met gebruik van ORM nog een functie schrijven die de juiste plaatsnaam ophaalt. Op die manier vormt ORM een extra laag, die niet nodig is als je data benadert via eenvoudige functies. Die functies zitten afgezonderd in een verzameling classes, een prima plek om alle SQL te concentreren. Het enige wat ORM dan toevoegt is dat ik vanuit die classes wel heel makkelijk de database kan lezen, maar ik heb een class voor een MySQL-database gemaakt waarmee het gebruik van SQL ook al heel simpel is geworden.

Ik snap niet waarom je voor een plaatsnaam een aparte functie nodig zou hebben. Over 't algemeen is een plaatsnaam een property van bijvoorbeeld een groter object. Als je dat object hebt, heb je ook de bijbehorende plaatsnaam.

[Kettrick]

SvMp schreef op dinsdag 05 oktober 2010 @ 16:33:
Er zal idd een God-class / monster-class ontstaan als je functies voor alle tabellen in één class samen brengt, ook al is het een bepaalde categorie functies. De class wordt flink groot als je een stuk of 20 verschillende data-objecten hebt. Daarom zou ik er voor kiezen om per data-object (plaats, klant, product, foto, etc..) een class te maken die alles met dat soort data kan. In situaties waarbij door gewone gebruikers de data alleen wordt gelezen, splits ik de class op in een algemeen gebruikte versie en een admin-versie waar alle schrijf-functies in zitten.

Het is me niet geheel duidelijk of je hier nou alsnog je database code wil combineren met je model .
Mijn ervaring is dat het combineren van data access en model code altijd een slecht idee is, ik zou er voor proberen te zorgen dat je een data laag maakt ( DAO ) welke je gebruik om je data op te halen. Ook zou ik een model gewoon plat houden en geen verschillende admin versies gaan maken. Waarom zou je dit doen ?

Ik ben het met je eens dat ORM's logisch in elkaar zitten. Dat is ook niet te reden dat ik er niet enthousiast over ben.
Een query uitvoeren kan niet met één simpele functie, maar een aantal functies die samen een query zullen uitvoeren. Het oogt als een abstractie van SQL. Om in een simpele functie-aanroep een plaatsnaam te krijgen zoals in het voorbeeld in mijn openingspost, moet ik ook met gebruik van ORM nog een functie schrijven die de juiste plaatsnaam ophaalt. Op die manier vormt ORM een extra laag, die niet nodig is als je data benadert via eenvoudige functies. Die functies zitten afgezonderd in een verzameling classes, een prima plek om alle SQL te concentreren. Het enige wat ORM dan toevoegt is dat ik vanuit die classes wel heel makkelijk de database kan lezen, maar ik heb een class voor een MySQL-database gemaakt waarmee het gebruik van SQL ook al heel simpel is geworden.

Een ORM is een laag die je achter je DAO zou kunnen plakken, het maakt uiteindelijk ook niet uit waar de data vandaan komt, of hoe. Of je dit nou zelf bij elkaar hackt of middels eigen SQL doet. Het voordeel van een dergelijke keuze is dat je kleine implementaties moet schrijven voor logische vragen aan je datamodel.

[YopY]

In situaties waarbij door gewone gebruikers de data alleen wordt gelezen, splits ik de class op in een algemeen gebruikte versie en een admin-versie waar alle schrijf-functies in zitten.

Kwestie: Waarom? Je kunt immers ook bij het aanroepen van de schrijffuncties eerst controleren of de huidige gebruiker die toegangsrechten heeft. Dat zul je sowieso moeten doen, overigens. Het is niet zo dat omdat je je schrijffuncties in een andere class zet dit 'veiliger' is. Het zorgt ook voor meer onderhoud - stel je hebt een Comment, in eerste instantie mogen alleen admins deze bewerken, maar later wil je dat ook je gewone leden deze kunnen bewerken. Dan mag je dus gaan refactoren.

+1 voor het scheiden van de toegangsfuncties in aparte classes, overigens. De logica voor het ophalen van (bijvoorbeeld) klanten en gegevens die daar direct aan gekoppeld zijn hoort in één class.

Toegang tot een functie hoort in een ACL, een lijst die aangeeft wie wat mag, niet in de uitvoerende partij zelf. imho, natuurlijk.

Het enige wat ORM dan toevoegt is dat ik vanuit die classes wel heel makkelijk de database kan lezen, maar ik heb een class voor een MySQL-database gemaakt waarmee het gebruik van SQL ook al heel simpel is geworden.

Correct, echter je moet nu ook nog voor elke query die je schrijft of aanpast code schrijven die de resultset van je query omzet in een data-object of, als je zover nog niet bent, de resultset naar html omzet. Dat is één van de redenen waarvoor je een ORM gebruikt - minder herhalende boilerplate code. Het ORM doet de omzetting van resultset naar model objecten.

[SvMp]

Kettrick schreef op dinsdag 05 oktober 2010 @ 16:58:
[...]

Het is me niet geheel duidelijk of je hier nou alsnog je database code wil combineren met je model .
Mijn ervaring is dat het combineren van data access en model code altijd een slecht idee is, ik zou er voor proberen te zorgen dat je een data laag maakt ( DAO ) welke je gebruik om je data op te halen. Ook zou ik een model gewoon plat houden en geen verschillende admin versies gaan maken. Waarom zou je dit doen ?

Ik combineer inderdaad database code met het model.
De eigenlijke applicatie bestaat een controller en uitvoer, zit dicht tegen Model–View–Controller (MVC) aan.

Wat is er mis met het combineren van model code en data access code? Bij omvangrijke projecten kan ik het mij wel voorstellen. Het is in mijn geval dusdanig beperkt dat de modelcode voor een groot deel uit data access bestaat.

Reden voor admin-versie: Admin versie is een stuk uitgebreider, waarom zou ik die altijd moeten laden terwijl in 99,9% van de requests er sprake is van een gewone gebruiker die genoeg heeft aan de alleen-lezen functies?

[SvMp]

YopY schreef op dinsdag 05 oktober 2010 @ 16:58:
[...]
Kwestie: Waarom?

Heb ik in mijn bovenstaande post over geschreven. Security-aspecten spelen hierbij uiteraard geen rol.

Correct, echter je moet nu ook nog voor elke query die je schrijft of aanpast code schrijven die de resultset van je query omzet in een data-object of, als je zover nog niet bent, de resultset naar html omzet. Dat is één van de redenen waarvoor je een ORM gebruikt - minder herhalende boilerplate code. Het ORM doet de omzetting van resultset naar model objecten.

Ik werk nu met simpele associatieve arrays waar de data in komt. Resultsets worden niet altijd 1-op-1 in html omgezet, wat er vervolgens met de data gedaan wordt verschilt per situatie.