[PHP/Alg] Patroon dilemma*

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Naar aanleiding van een artikel op PHPBuilder ben ik een 'data access object' systeempje aan het maken. Een 'frontend', een 'datarecord' en een 'object storage'. Een methode om klassen enigzins simpel in een database te plaatsen dus.

Relevante klasse vingerafdruk:

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<?php

class Storage { 
    /* ... */
    function storeRecord() {}
}

class SqlRecord {
    function getColumn() { }
    function setColumn() { }
}

class Storable {
    function Storable() { /* Initialiseert een SqlRecord */ }
    
    /* Heeft X aantal accessors/modifiers als volgt: */
    function SetField ( $mValue ) 
    { 
        $this->_oSqlRecord->setColumn('Field', $mValue);
    }
}
 
?>


Dilemma is nu als volgt: ik kan de klasse 'SqlRecord' verantwoordelijk maken voor het genereren van relevante sql queries (INSERT/DELETE/UPDATE). Of ik kan deze functionaliteit insluiten in de klasse Storage. Storage is in dit geval een simpele wrapper om het PEAR package DB.

Argumenten voor/tegen generatie in SqlRecord:
- [voor] Storage hoeft niet te weten hoe hij de kolommen uit SqlRecord hoeft te halen
- [voor] SqlRecord heeft waarschijnlijk toch al een methode initialiseerUitDb(), dus praat daar al met DB
- [tegen] Verschillende klasse voor elke soort database, verlies daarmee de kracht van het gebruik van 'PearStorage'.

Waarschijnlijk nog wel een paar meer, maar ik zit vooral met het tegenargument. Hoe zou jij dit doen? Want ik zit hier een beetje vast mee. In mijn ogen is voor allebei iets te zeggen, maar kom er niet helemaal uit.

[ Voor 8% gewijzigd door Verwijderd op 20-05-2003 19:46 ]


Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 23:16
Als je je classes ook voor andere DBMS'en wilt gebruiken, dan heb je toch ook voor ieder type DB dat je ondersteund een andere Storage class nodig?

Je zou kunnen gebruik maken van een factory patroon, alleen vrees ik dat dat niet zal lukken in PHP. (Tenzij PHP al inheritance ed ondersteund...)

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Anyway, de PEAR DB klasse is al een database abstraction op zich, welke dmv een DSN en een factory methode de klasse voor de relevante DBMS levert. Ik zie dat ik vergeten ben te zeggen dat de 'klasse voor elke soort database' een extra SqlRecord voor elke soort database. Dan eindig ik met de PEAR db klassen en m'n extra SqlRecord (MysqlRecord, PgsqlRecord) klassen.

Acties:
  • 0 Henk 'm!

Verwijderd

Heb je al iets van een klassendiagram?
Dat verduidelijkt je idee en zorgt voor wat overzicht.
Maar dat is meer voor je hele systeem bedoelt.

Ik zou voor het maken van de query een aparte klasse maken die alles voor je genereert.
Dus dan vraag je aan SqlRecord de kollomen, en aan je andere klasses de table etc.
Dat geef je aan je query-klasse, en die doet het vieze werk.

En voor whoami, inheritance wordt ondersteunt, maar dingen als interfaces (nog) niet (in php5 wel).

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Maar, is dat niet een beetje krom dan? In principe heb ik dan aan de ene kant de stabel DBA klassen en dan moet ik nog een extra stapel Query klassen gaan bouwen.. Aan de andere kant is het insluiten van SQL logica in Storage met die gedachtegang niet echt een puik idee.

Acties:
  • 0 Henk 'm!

  • sebas
  • Registratie: April 2000
  • Laatst online: 03-09 12:51
whoami schreef op 20 mei 2003 @ 19:39:
Je zou kunnen gebruik maken van een factory patroon, alleen vrees ik dat dat niet zal lukken in PHP. (Tenzij PHP al inheritance ed ondersteund...)
Ik heb de laatste tijd een beetje gekeken naar de OOP implementatie in PHP, en het ondersteunt wel inheritance. Ook overloading werkt, alleen Operator Overloading ben ik nog niet tegengekomen.

Ik zou in elk geval het opslaan, dus alles wat database specifiek is in een aparte class zetten, deze kun je dan met andere classes uitbreiden om interfaces ook voor andere database te maken. Je maakt dus een SQL class, dat bijvoorbeeld standaard SQL gebruikt, en dan een class MySQL die de methods in SQL override die afwijken van de MySQL syntax, hetzelfde kun je dan ook voor andere database toepassen.

Everyone complains of his memory, no one of his judgement.


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
sebas schreef op 20 May 2003 @ 20:48:
[...]


Ik heb de laatste tijd een beetje gekeken naar de OOP implementatie in PHP, en het ondersteunt wel inheritance. Ook overloading werkt, alleen Operator Overloading ben ik nog niet tegengekomen.
Er is geen operator overloading in PHP en er komt geen operator overloading in PHP.

Acties:
  • 0 Henk 'm!

Verwijderd

Verwijderd schreef op 20 May 2003 @ 20:01:
Maar, is dat niet een beetje krom dan? In principe heb ik dan aan de ene kant de stabel DBA klassen en dan moet ik nog een extra stapel Query klassen gaan bouwen..
Ja, dat is waar, maar waarom maak je dan niet gewoon 1 grote klasse die alles regelt (ik bedoel dus te zeggen, zet alles waar het hoort te staan).
Aan de andere kant is het insluiten van SQL logica in Storage met die gedachtegang niet echt een puik idee.
Dat bedoel ik, het probleem is dat je van meerdere objecten data nodig hebt.

Ik verwacht dat je systeem er ongeveer zo uit ziet:
code:
1
2
3
- Database
  |- SqlResult
    |- SqlRecord

In de Database klasse voer je de query uit, je krijgt een result terug.
En met dingen als locate, next en prior kan je je active record wijzigen.

Nu lijkt me dat je dus het makkelijkst in Database een method aan roept die alle data verzameld (tabel, kollomen, etc) en die doorgeeft aan een query object.
Pagina: 1