[kampfgnom]

Hi, kann mir jemand irgendwie ein Tutorial geben wo das Table Data Gateway Pattern erklärt wird?
In meinem Buch (PHP Design Patterns) wird an der Stelle einfach auf Propel verwiesen. Das nützt mir ja nichts.

[dr.e.]

Hallo Gabriel,

beim TDGW-Pattern handelt es sich - kurz gesprochen - um einen Wrapper auf eine Tabelle. Implementierst du das, sollte deine Klasse die Methoden delete(), update() delete(), ... haben.

Sollte dich das Thema Mapping interessieren, kannst du ja auch mal unter http://de.adventure-php-framework.or...cher-OR-Mapper vorbeischaun.

[kampfgnom]

Zitat von dr.e.

Hallo Gabriel,

beim TDGW-Pattern handelt es sich - kurz gesprochen - um einen Wrapper auf eine Tabelle. Implementierst du das, sollte deine Klasse die Methoden delete(), update() delete(), ... haben.

Das ist mir Prinzipiell klar. Was mich grad zum stocken bringt ist die Abstrakte implementierung.
Soll ich wirklich eine Abstrakte klasse machen á la:

PHP-Code:

/**
 * Pseudocode
 **/
abstract class TableDataGateway_Abstract 
{
    public function delete ($id) {
        $sql = "DELETE ...";
        execute_query($sql);
    }
    public function insert ($data = array()) {
        $sql = "INSERT ...";
        execute_query($sql);
    }
    public function update ($id, $data=array())
    {
        $sql = "UPDATE...";
        execute_query($sql);
    }
} 


ODer wie meinst du das?

[dr.e.]

Hallo Gabriel,

ja, es sollte abstrakt sein. Das erreichst du durch eine Art "auto-discover", sprich die Factory, die dir dein konkretes gateway erstellt wird mit dem Namen der Tabelle initialisiert und erzeugt das Gateway mit den wichtigen Informationen über die Tabelle. Andere Möglichkeit ist eine Konfiguration, die die interessanten Parameter beinhaltet und diese beim Erstellen des konkreten Gateways diese and Hand eines Init-Parameter an die Fabric erzeugt. Letzteres habe ich für den GenericORMapper gewählt.

Allerdings würde ich die Klasse zwar mit "abstract" bezeichnen, sie jedoch nicht als "abstract" deklarieren, denn über die Factory ist sie ja konkret anwendbar.

[kampfgnom]

Ich muss sagen, erstere Möglichkeit klingt sehr verlockend. Nur hab ich noch keinen Schimmer wie ich das Umsetzen söllte, oder vlt hab ich auch einfach falsch vorstellungen.
Das Factorypattern fasst ja letztlich alle gleichen Methoden zusammen und lässt nur die Initialisierung eines Objekts offen, oder irre ihc mich da?

Iwie stehe ich grad derbste aufm Schlauch!

[dr.e.]

Hallo Gabriel,

ich vermute, du stellst dir das Thema zu schwer vor. Ich helfe dir mal mit ein bischen Quellcode:

PHP-Code:

   class TableDataGateWayFactory
   {

      var $__gateways = array();

      function TableDataGateWayFactory(){
      }

      function &getGateway($TableName,&$DatabaseDriver){

         // return cached driver, if the driver already is initialized
         $gatewayKey = md5($TableName);

         if(isset($this->__gateways[$gatewayKey])){
            return $this->__gateways[$gatewayKey];
         }

         // discover the desired table by use of the database driver.
         // the database driver is an instance of a database abstraction class.
         $primaryKeyName = ...

         // initialize the desired gateway and add it to the cache
         $this->__gateways[$gatewayKey] = new AbstractTableDataGateWay();
         $this->__gateways[$gatewayKey]->setTable($TableName);
         $this->__gateways[$gatewayKey]->setPrimaryKeyName($primaryKeyName);
         ...

         // return driver
         return $this->__gateways[$gatewayKey];

      }
   }

   class AbstractTableDataGateWay
   {

      var $__databaseDriver = null;
      var $__table = null;
      var $__primaryKeyName = null;

      function AbstractTableDataGateWay(){
      }

      function update(){
         ...
      }

      function create(){
         ...
      }

      function delete(){
         ...
      }

      function select($id){

         $select = 'SELECT * FROM '.$this->__table.' WHERE '.$this->__primaryKeyName.' = \''.$id.'\';';
         $result = $this->__databaseDriver->executeTextStatement($select);
         $data = $this->__databaseDriver->fetchData($result);

         $item = new TableDataGateWayItem();
         foreach($data as $rowName => $rowValue){
            $item->setAttribute($rowName => $rowValue);
         }

         return $item;

      }

      function selectList($ids = array()){
         ...
      }

      function setDatabaseDriver(&$databaseDriver){
         $this->__databaseDriver = $databaseDriver;
      }

      function setTable($table){
         $this->__table = $table;
      }

      function setPrimaryKeyName($primaryKeyName){
         $this->__primaryKeyName = $primaryKeyName;
      }

   }


   class TableDataGateWayItem
   {

      var $__attributes = array();

      function TableDataGateWayItem(){
      }

      function setAttribute($name,$value){
         $this->__attributes[$name] = $value;
      }

      function getAttribute($name){
         return $this->__attributes[$name];
      }

   } 


Die Anwendung gestaltet sich dann so, dass du zunächst über die Factory dein konkretes Gateway ziehst - dabei sollte sinnvollerweise eine Datenbank-Abstraktion übergeben werden - und dieses dann z.B. per select() nach einem Datensatz fragst. Da es nicht nur ein RowDataGateway ist, solltest du entsprechende Methoden vorsehen - habe ich mit selectList() angedeutet - die dir entsprechend eine Tabelle zurückgeben. Diese besteht in meiner Implementierung aus einer Liste von Item-Objekten. Ist sicher nicht der Weisheit letzter Schluss, aber ich habe mir auch nur 10Min gegeben.

Ich hoffe, das hilft dir als Gedanken-Anstoss weiter. :)

[kampfgnom]

Würde ich dann meine Konkreten klassen (also zum Beispiel eine Navigation) von AbstractTableDataGateWay ableiten und noch ein paar mehr Funktionen implementieren?

Aber vielen Dank erstmal so Grundsätzlich für deine Hilfe. Hilfst mir ja nun nicht zum erstenmal auf die Srpünge!

[dr.e.]

Würde ich dann meine Konkreten klassen (also zum Beispiel eine Navigation) von AbstractTableDataGateWay ableiten und noch ein paar mehr Funktionen implementieren?

Nein, das würde ich nicht tun, sondern für deine Menü-Komponente diese nutzen. Das sieht in der Praxis so aus, dass du beispielsweise einen Menü-Manager implementierst, der der Präsentationsschicht eine definierte API zur Verfügung stellt. Die Pres kann dann z.B. den Manager nach dem Navi-Baum fragen oder bearbeiten - also Methoden, die im Backend benötigt werden.

Der Manager wiederum nutzt das AbstractTableDataGateWay (abstract hier einfach, weil das Teil generisch wiederverwendbar ist) dann als Datenschicht seiner Anwendung. Sollte es mit dem TDGW nicht möglich sein auf einfache Weise die Anforderungen des Managers zu befriedigen, würde ich noch eine eigene Datenschicht für deine Menü-Komponente spendieren, die jedoch auch die TDGW-Komponente als Data-Access-Layer nutzt.

Direkt erben hat den Nachteil, dass du dir eine direkte Abhängigkeit schaffst, die es nicht erlaubt, deine DAO-Komponente gegen eine andere der gleichen API auszutauschen. Möchtest du z.B. später - weil das TDGW nicht mehr den Anforderungen entspricht - einen GenericORMapper einsetzen, so kannst du einfach eine Zeile austauschen und bist fertig. :)

Aber vielen Dank erstmal so Grundsätzlich für deine Hilfe. Hilfst mir ja nun nicht zum erstenmal auf die Sprünge!

Danke, das höre ich gerne! :)

[kampfgnom]

Das Problem bei der "Abstrakten" Klasse ist ja aber genau das, dass sie abstrakt ist. Also keine für den Anwendungszweck zugeschnittenen Methoden hat. Letztlich müsste ich mich dann im Navimodul trotzdem um SQL Code kümmern. Das ist ja nicht Sinn der Sache, oder hab ich jetzt schon 9:00 Uhr am Morgen ne Denkblockade

Noch eine Frage die sich mir gerade stellt:
Ist die Factoryklasse dann eigentlich im Singletonepattern implementiert? Sonst würde der Cache ja mal so gar nichts bringen oder?!

[dr.e.]

Hallo Gabriel,

Das Problem bei der "Abstrakten" Klasse ist ja aber genau das, dass sie abstrakt ist. Also keine für den Anwendungszweck zugeschnittenen Methoden hat.

Warum denn nicht? Du musst deine Klasse eben so implementieren, dass diese für jeden Anwendungsfall passt. Das bedeutet, dass die Methoden so generisch wie möglich sind. :) In meinem Beispiel ist das an sich auch schon der Fall. Die konkrete Nutzung definiert dann erst den konkreten Anwendungsfall. Das anders aufzuziehen verbaut dir ein bischen die Wiederverwendbarkeit.

Letztlich müsste ich mich dann im Navimodul trotzdem um SQL Code kümmern. Das ist ja nicht Sinn der Sache, oder hab ich jetzt schon 9:00 Uhr am Morgen ne Denkblockade

Das Navi-Modul muss sich - wie auch ohne TDGW - um seinen Code kümmern. Da du den SQL-Code im TDGW erzeugst und im Navi-Modul nur die Wrapper-Methoden nutzt. Nicht so kompliziert denken, es geht hier um die Abstraktion in unterschiedlichen Schichten.

Noch eine Frage die sich mir gerade stellt:
Ist die Factoryklasse dann eigentlich im Singletonepattern implementiert? Sonst würde der Cache ja mal so gar nichts bringen oder?!

Ich habe das im obigen Beispiel so gewählt, da ich im APF immer eine abstrakte Singleton-Implementierung nutze:

PHP-Code:

$db = &Singleton::getInstance('MySQLHandler');
$tdgwFab = &Singleton::getInstance('TableDataGateWayFactory');
$tdgw = &$tdgwFab->getGateway('my_table',$db);
... 


[kampfgnom]

Was sagst du dazu:

PHP-Code:

<?php
abstract class Kanedo_Table_Data_Gateway_Abstract
{
    protected $table;
    
    protected $primary;
    
    protected $dbConnector;
    
    public function __construct()
    {
        
    }
    public function init($tablename, $connector)
    {
        $this->dbConnector = $connector;
        $this->table = $tablename;
        $this->primary = get_primary_key(); //Muss ich mir noch überlegen, wie ich das mache!
    }
    public function update()
    {
        //@todo SQL Code
    }
    public function select()
    {
        //@todo SQL Code
    }
    public function delete()
    {
        //@todo SQL Code
    }
}

class Kanedo_Factory 
{
    protected $gatewayCache = array();
    protected function __construct()
    {
        /**
         * Singletone
         */
    }
    
    function getGateway($TableName,$DatabaseDriver)
    {
        if (key_exists($TableName, $this->gatewayCache))
        {
            return $this->gatewayCache[$TableName];
        }
        
        include 'Pfad/zu/Gate/Way/Klasse/'.$TableName.'.php';
        $gw = new Pfad_zu_Gate_Way_Klasse();
        if ($gw instanceof Kanedo_Table_Data_Gateway_Abstract)
        {
            $gw->init($TableName, $DatabaseDriver);
            $this->gatewayCache[$TableName] = $gw;
            return $gw;
            
        }else {
            throw new Exception();
        }
   } 
}

class Nested_Sets extends Kanedo_Table_Data_Gateway_Abstract 
{
    public function getTree()
    {
        /*
         * SQL Code zum auslesen des Kompletten baums
         */
    }
}

$ns = Kanedo_Factory::getInstance()->getGateway('Nested_Sets', $connector);
echo $ns->getTree();
?>

Damit hab ich zwei Vorteile. Ich brauch mich in der Klasse nicht mehr um Grundlegende Datenbank kommunikation zu Kümmern, hab sie aber inidviduell erweitert und initialisiert wird sie von der Factory!

Was meisnt du?!

[dr.e.]

Hallo Gabriel,

Kanedo_Table_Data_Gateway_Abstract

Ich finde diese benennung so unnatürlich. Man muss nicht alles von Zend übernehmen...

Kanedo_Factory

Diese Benennung ist auch irreführend, da kein Bezug hergestellt wird, welche Objekte erzeugt werden.

include 'Pfad/zu/Gate/Way/Klasse/'.$TableName.'.php';

Das würde ich so nicht implementieren, denn sonst bist du auf den angegebenen Namespace angewiesen. Weiterhin verwendest du wieder konkrete Implementierungen für einzelne Tabellen. Das spart nicht wirklich Tipparbeit.

[kampfgnom]

Zitat von dr.e.

Hallo Gabriel,

Ich finde diese benennung so unnatürlich. Man muss nicht alles von Zend übernehmen...

Was is daran so schlimm? Ich finde, daran findet man zumidnest schnell heraus wo die Datei liegt!

Zitat von dr.e.

Diese Benennung ist auch irreführend, da kein Bezug hergestellt wird, welche Objekte erzeugt werden.

Das war ja nur schnell hingeschrieben. Den Namen muss ich noch genauer Spezifizieren.

Zitat von dr.e.

Das würde ich so nicht implementieren, denn sonst bist du auf den angegebenen Namespace angewiesen. Weiterhin verwendest du wieder konkrete Implementierungen für einzelne Tabellen. Das spart nicht wirklich Tipparbeit.

Naja, aber sonst muss ich mich trotzdem um logik kümmern oder? Das spart genauso keine Tipparbeit!
Die Methoden die man implementieren kann, dass sie auf alle Tabellen passen sind viel zu abstrakt als das sie nützlich wären.

[dr.e.]

Was is daran so schlimm? Ich finde, daran findet man zumidnest schnell heraus wo die Datei liegt!

Die Bennennung ist unnatürlich hinsichtlich den Regeln der Sprache. Du sagst ja auch nicht

Straße der Ende liegt Haus das

oder doch? Weiterhin sollte - siehe JAVA - die Eindeutigkeit über den Namespace hergestellt werden.

Naja, aber sonst muss ich mich trotzdem um logik kümmern oder? Das spart genauso keine Tipparbeit!
Die Methoden die man implementieren kann, dass sie auf alle Tabellen passen sind viel zu abstrakt als das sie nützlich wären.

Ich glaub das hast du nicht verstanden. Tipparbeit sparst du dir nur, wenn du die Implementierung so allgemeingültig hälst, dass die auf alle Tabellen anwendbar ist! Der Anwendungsfall NestedSet hat zunächst nichts mit dem TDGW zu tun. Wenn du dich da schon in Anwendungsfällen verstrickst, wirst du es nicht schaffen, das generisch zu implementieren. Versuche hier einfach in Schichten und kleinen Komponenten zu denken.

BTW: NestedSets sind auch eine denkbar schlechte Anwendung für das TDGW.

[kampfgnom]

Zitat von dr.e.

Ich glaub das hast du nicht verstanden.

Das glaub ich auch

Zitat von dr.e.

Tipparbeit sparst du dir nur, wenn du die Implementierung so allgemeingültig hälst, dass die auf alle Tabellen anwendbar ist! Der Anwendungsfall NestedSet hat zunächst nichts mit dem TDGW zu tun. Wenn du dich da schon in Anwendungsfällen verstrickst, wirst du es nicht schaffen, das generisch zu implementieren. Versuche hier einfach in Schichten und kleinen Komponenten zu denken.

Ok, das akzeptier ich jetzt mal so, weil ich einfach keine Erfahrung habe.

Allerdings habe ich eine Frage zu deinem Vorher geposteten Quellcode.
Du übergibst ein $DatabaseDriver. Was genau kann der?
Bisher hab ich eine Verbindungsklasse, die mit Api klassen versorgt wird. So wird sichergestellt, das die Verbindung über eine Art Proxy unabhängig von der Verwendeten Datenbank möglich ist.
Diese API Klassen implementieren alle ein Interface.

Aber die machen letztlich nichts anderes als die Verbindung aufzubauen und die Verbindungsressource zurück zugeben.

Sollte ich da schon verschiedene Fkt wie Select, Update, Delete, etc. einbauen.
Bzw. ist meine "API Klasse" das was bei dir der DatabaseDriver ist?
Vielleicht komme ich so schneller dahinter wie das funktioniert.

[dr.e.]

Hallo Gabriel,

der DatabaseDriver ist eine Service-Schicht, die den Zugriff auf die Datenbank abstrahiert. Diese bietet Methoden wie executeStatement() bzw. fetchData(). Eine Definition so einer Klasse findest du unter http://adventure-php-framework.org/f...l_handler.html Im APF abstrahiere ich eine konkrete Datenbank-Verbindung noch mit dem connectionManager, der als Datenbank-Verbindungs-Factory dient.

Eine konkrete Implementierung einer Methode kann dabei im APF wie folgt aussehen:

PHP-Code:

function create($item){
   $cM = &$this->__getServiceObject('core::database','connectionManager');
   $sql = &$cM->getConnection('my_connection_key');
   $insert = $this->__createStatementByItem($item);
   $sql->executeTextStatement($insert);
} 


$item ist dabei eine Instanz der Klasse TableDataGateWayItem. Unter __createStatementByItem() verstehe ich eine Methode, die dir eine konkretes Statement bastelt. Je nach dem, ob bereits das Primary-Key-Attribut im Item enthalten ist oder nicht, kommt da ein INSERT oder UPDATE raus. So kannst du das intern nochmals sauber abstrahieren.

Soweit klar?