Datenbank austauschbar machen durch Trennung von konkreter Implementierung

Asipak · 01.09.2009, 16:13

Hallo alle miteinander,

vor ein paar Tagen ist mein Buch zum Thema PHP Design Patterns angekommen und ich habe mich damit beschäftigt, eine Datenbank (z.B. MySQL) gegen eine andere (z.B. XML Dateien) leicht austauschbar zu machen.

Als Beispiel zur Übung dient mir hierzu eine Klasse User, die ihre Daten von einer Datenbank bekommen soll. Das ganze sah dann zunächst so aus:

Konkrete Implementierung › Ablage › ubuntuusers.de

Ein Objekt der Klasse User wird jeweils mit einer ID und einem Namen instanziert. Dazu lese ich einmal Daten aus einer MySQL - Datenbank

Code:

id | name
1  | Name1
2  | Name2

aus und gleich danach kommen die Daten aus einer XML Datei:

database.xml

PHP-Code:

  <?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE database PUBLIC "database" "database.dtd">
<database>
  <user>
    <id>
      1
    </id>
    <name>
      Name1
    </name>
  </user>
  <user>
    <id>
      2
    </id>
    <name>
      name2
    </name>
  </user>
</database>

Auslesen der Daten:

PHP-Code:

  $sql = "SELECT
              `id`      ,
              `name`    
        FROM
              `users`
";
$result = mysql_query($sql, $c) OR die (mysql_error());

echo '<h1>MySQL Datenbank</h1>';

while ($row = mysql_fetch_array($result)) {
  $user = new User($row["id"], $row["name"]);

  echo '<p>' . $user->getName() . '</p>';
}

echo '<h1>XML Datei als Datenbank</h1>';

$data = simplexml_load_file('../xml/database.xml');

foreach ($data->user as $concrete_user) {
  $user = new User($concrete_user->id, $concrete_user->name);

  echo '<p>' . $user->getName() . '</p>';
}

Das funktioniert natürlich super, aber ich müsste so ja jedesmal die konkrete Implementierung zum Auslesen und Ausgeben der Daten anpassen, wenn ich die Datenbank wechseln möchte.

Ich hab mir also angeschaut was gleich ist: Auslesen der Daten und als User-Objekte zurückgeben.
Wenn ich die Userobjekte erst einmal habe, bleibt nur noch:

PHP-Code:

  echo '<p>' . $user->getName() . '</p>';

übrig.

Daher habe ich mir ein Interface angelegt, dass von beiden Datenbankklassen erwartet, dass sie eine Funktion bereitstellen, um sämtliche User aus der Datenbank auslesen zu können, damit ich die Benutzer als Objekte zurückerhalte.

PHP-Code:

  interface UserAdministration {
  public function getUsers();
  public function getUserById($id);
}

Das Script sieht mitlerweile so aus:

Verwendung von Klassen › Ablage › ubuntuusers.de

Der Aufruf und die Ausgabe erfolgt dann so:

PHP-Code:

  $users = new XML_Database_Users('xml/database.xml');
//$users = MySQL_Database_Users::getInstance();

foreach ($users->getUsers() as $user) {
  echo '<p>' . $user->getName() . '</p>';
}

Genau das, was ich haben wollte. So brauche ich zumindest nur noch der Variablen $users ein Objekt der Klasse übergeben, die das Interface implementiert und mit der ich die Daten auslesen kann.

Ich habe die Klassen

abstract class MySQL_Database {

und

abstract class XML_Database {

als abstrakt definiert, da ich von ihnen ja noch weitere Klassen ableiten kann, mit denen ich dann z.B. anstelle von Userdaten, Termine eines Kalenders o.ä. auslesen könnte! Diese würden dann aber wieder ein anderes Interface implementieren müssen.

Ich stelle mir gerade vor, dass ich für jede "wichtigere" Tabelle, die ich in einer MySQL-Datenbank habe, eine Klasse von der Klasse MySQL_Database ableiten und jeweils ein neues Interface erzeugen oder ableiten müsste.

Ist das ein Schritt in die richtige Richtung oder kann ich mich bald vor Klassen nicht mehr retten?
Mir fällt momentan leider keine Idee ein, wie ich die Daten noch weiter zusammenfassen könnte.

Vielleicht wenn ich dem Interface eine allgemeinere Bezeichnung verpasse:

PHP-Code:

  interface DatabaseAdministration {
  public function getEntries();
  public function getEntryById($id);
}

?

Ich möchte eigentlich nur wissen, ob ich damit so weiterarbeiten kann oder ob ich doch lieber grundlegend etwas ändern sollte und wenn ja, was?

Gruß

rudygotya · 01.09.2009, 17:12

Hab nicht viel Zeit, deswegen wird die Antwort knapp.

Wie wäre es denn in diesem Fall mit einer abstrakten Klasse Database_Adapter? Welcher Adapter benutzt wird, regelst du über eine externe Konfiguration.

In der getUser sollte der Zugriff auf das Model dann nur noch über den Adapter oder über eine abgeleitete Modelklasse erfolgen, nicht mehr direkt mit mysql_* Funktionen. Dazu am besten noch speziell Model Klassen anlegen, die deinen db Adapter erweitern.

Hier mal ein Beispiel aus einer Modelklasse in Verwendung mit dem Zend Framework Model Adapter:

PHP-Code:

  class User implements Iterator extends Zend_Db_Table_Abstract {

    protected $_input  = array();
    protected $_output = NULL;
    protected $_entries = NULL;

    public function init() {
    // hook 
    }

/**
     * @return int (number of entries in db)
     */
    public function getDbEntries () {
        $this->_entries = intval($this->_entries);
        return abs($this->_entries);
    }

    /**
     * @return int (number of entries in current result set)
     */
    public function countResultSet () {
        $n = count ($this->_output);
        $n = intval($n);
        return abs($n);
    }
    public function rewind()
    {
        reset ($this ->_output);
    // end function
    }

    public function next()
    {
        return next($this -> _output);
    // end function
    }
    public function current()
    {
        return current($this -> _output);
    // end function
    }

    public function key()
    {
        return key ($this -> _output);
    // end function
    }

    public function valid()
    {
        return $this -> current() !== false;
    // end function
    }

grüße

edit:

Zitat:

Ist das ein Schritt in die richtige Richtung oder kann ich mich bald vor Klassen nicht mehr retten?

ja UND ja

Chriz · 01.09.2009, 20:56

Also Zend_Db_Table (Table-Gateway) mag ich garnicht, abgesehen davon ist eine Komposition wohl sicherlich angebrachter als eine Ableitung, denn ein User ist keine Spezifizierung einer Datenbank, sondern benutzt diese lediglich.

Ich habe zum Thema Models unabhängig von der Datenquelle schon einmal eine Art Tutorial geschrieben:
http://www.php.de/tutorials/54558-tu...l-und-oop.html (Tutorial: PHP/MySQL und OOP)
Ich muss zugeben, die Klassen habe ich mittlerweile bei mir stark überarbeitet, ich muss es demnächst mal aktualisieren. Was aber noch aktuell ist, ist das Konzept an sich.

Beim Interface hast du die Problematik, dass Datenbank und XML möglicherweise ganz anders arbeiten und eine gleiche Schnittstelle deswegen nicht immer hinzubekommen ist, bzw. performant hinzubekommen ist. So kann ich beispielsweise auch die Session als Persistenzschicht neben der DB oder einem XML verwenden, und die Session muss auf Performance kaum Rücksicht nehmen (serialize/unserialize sind extrem schnell), bei der Datenbank muss ich aber drauf achten, dass ich bei jeder Änderung nicht das komplette Objekt wieder in der DB aktualisiere, weil das durch Fremdschlüssel etc. möglicherweise einen riesigen Overhead annimmt. Nur wie bringt man das in ein gemeinsames Interface?

robo47 · 01.09.2009, 21:37

Nur mal so semi-topic:

Wenn ich solche Ansätze sehe muss ich immer an LINQ denken, gibt dafür zumindest im Ansatz (weis nicht wie weit die sind) was in PHP der geht aber wahrscheinlich noch über dein Interesse hinaus, aber nur um es mal erwähnt zu haben.

Damit kann man noch einen Schritt weiter gehen und muss sich nicht direkt um Model-spezifische Methoden kümmern sondern stellt einen sql-ähnlichen Ansatz hin mit dem man auf unterschiedliche Datentypen zugreifen kann, sei es xml, eine sql-datenbank.

PHPLinq - LINQ for PHP - Language Integrated Query - Home

nikosch · 02.09.2009, 00:56

Sonderbares Konzept.

xm22 · 03.09.2009, 09:13

Das Konzept von Chriz habe ich vor einiger Zeit auch übernommen. Das ist besonders dann vorteilhaft, wenn man die Queries des Managers möglichst reduziert. Dann ist der Portierungsaufwand - selbst, wenn es auf einen Webservice oder sonst was geht, sehr gering.

Flor1an · 03.09.2009, 09:50

Irgendwie kommt mir Linq auch komisch vor. Code als String anzugeben wiederstrebt mir irgendwie. Damit lassen sich automatische checks durch den Editor schlecht machen. Auch Refactoring oder sonst was wird schwer ...

Asipak · 03.09.2009, 09:59

Hmm, Käse

Danke für eure Antworten, aber ich merke leider, dass ich keine sinnvolle Antwort geben kann. Dazu fehlt mir momentan wohl einfach noch das Wissen über die Materie und ich muss erst in meinem schönen Buch ein paar Kapitel weiterlesen.

Zitat:

Zitat von Chriz

[...]abgesehen davon ist eine Komposition wohl sicherlich angebrachter als eine Ableitung, denn ein User ist keine Spezifizierung einer Datenbank, sondern benutzt diese lediglich.

Ja, schon richtig, ich weiß nur leider nicht wie ich dieses "Benutzen" umsetzen soll!

So habe ich es meist bislang gemacht, von Austauschbarkeit keine Spur, die Klasse ist von der gewählten Datenbank abhängig:

PHP-Code:

  class User {
  private $db   = null;

  private $id;
  
  private $name;

  public function __construct($db) {
    $this->db = $db;
  }

  public static function newUser($name) {
    // user anlegen
  }

  public function prepare_user($id) {
    // Daten aus Dartenbank auslesen 
    $sql = "";

    $this->db->query($sql);
  }

  public function getId() {
    return $this->id;
  }

  public function getName() {
    return $this->name;
  }

  // ...
}

Ein neuer User wird dann mithilfe einer statischen Funktion angelegt, da ja noch keine ID existiert.

Zitat:

Ich habe zum Thema Models unabhängig von der Datenquelle schon einmal eine Art Tutorial geschrieben:
http://www.php.de/tutorials/54558-tu...l-und-oop.html (Tutorial: PHP/MySQL und OOP)

Das muss ich mir mal in Ruhe anschauen und am besten ausprobieren. Verstehe momentan noch nicht, wie ich da den Zugang zur Datenbank herstelle. Die Daten liegen ja immer bereits als Array vor und werden dann in die Klasse geladen!?

Zitat:

Zitat von robo47

PHPLinq - LINQ for PHP - Language Integrated Query - Home

Auch das werd ich mir mal in einer ruhigen Minute anschauen müssen

Zitat:

Zitat von nikosch

Sonderbares Konzept.

Meins? LINQ? Oder beide?

Werd mich wieder melden, wenn ich etwas weiter bin und dann den Thread ausgraben.

Gruß

Chriz · 03.09.2009, 10:49

Zitat:

Zitat von Asipak

Ja, schon richtig, ich weiß nur leider nicht wie ich dieses "Benutzen" umsetzen soll!

Zitat:

PHP-Code:

    public function __construct($db) {
    $this->db = $db;
  }

Definiere von welchem Klassentyp $db sein soll, sonst kann ich dir auch einen Integer als $db übergeben, was sicherlich nicht gewollt ist:

PHP-Code:

    public function __construct(MyDatabaseClass $db) {
    $this->db = $db;
  }

So und statt deiner konkreten MyDatabaseClass kannst du auch einfach ein Interface übergeben:

PHP-Code:

    public function __construct(MyUserManagerInterface $db) {
    $this->db = $db;
  }

Sprich es können nun mehrere Klassen übergeben werden, sofern sie das Interface implementiert haben (das garantiert dir der PHP-Parser).

Zitat:

Zitat von Asipak

So habe ich es meist bislang gemacht, von Austauschbarkeit keine Spur, die Klasse ist von der gewählten Datenbank abhängig:

PHP-Code:

  class User {
  // ..
  public function prepare_user($id) {
    // Daten aus Dartenbank auslesen 
    $sql = "";

    $this->db->query($sql);
  }
  // ...
}

Hier liegt der Fehler. Übergibst du einen Datenbank-Adapter, bleibt dir nichts anderes übrig als direkt Queries zu verwenden. Damit hast du dich fest gebunden. Mit Zend_Db könntest du allerdings Queries generieren, die je nach Zend_Db_Adapter auf alle verfügbaren Datenbanken passen, obwohl sich die Syntax leicht unterscheidet (MySQL, Oracle, SQLite, ..). In dem Thread den ich gepostet habe gehe ich allerdings den umgekehrten Weg. Nicht die User-Klasse holt sich die Daten (denn dann muss sie wissen woher sie kommen), sondern ein Manager füllt ein User-Objekt mit Daten. Dann bleibt dein User-Objekt immer gleich (und frei von Queries), und wenn du die MySQL mal gegen eine Oracle austauscht, wechselst du einfach nur den Manager.

PHP-Code:

  <?php
$manager = $this->_getDefaultUserManager();
$user = $manager->getUser(1);
?>

Zitat:

Ein neuer User wird dann mithilfe einer statischen Funktion angelegt, da ja noch keine ID existiert.

Statische Funktionen/Methoden solltest du vermeiden.

Zitat:

Das muss ich mir mal in Ruhe anschauen und am besten ausprobieren. Verstehe momentan noch nicht, wie ich da den Zugang zur Datenbank herstelle. Die Daten liegen ja immer bereits als Array vor und werden dann in die Klasse geladen!?

Auf meinen Thread bezogen? Ja so ähnlich. Woher dieser Array dann kommt entscheidest du.

Asipak · 03.09.2009, 22:45

Zitat:

Zitat von Chriz

Definiere von welchem Klassentyp $db sein soll, sonst kann ich dir auch einen Integer als $db übergeben, was sicherlich nicht gewollt ist:

Ja, das sind alles noch meine ersten Schritte gewesen die ich nun ändern möchte!

Zitat:

So und statt deiner konkreten MyDatabaseClass kannst du auch einfach ein Interface übergeben:

PHP-Code:

    public function __construct(MyUserManagerInterface $db) {

    $this->db = $db;

  }

Sprich es können nun mehrere Klassen übergeben werden, sofern sie das Interface implementiert haben (das garantiert dir der PHP-Parser).

Ja, so langsam entwickelt sich bei mir auch ein Verständnis dafür. In einigen Quellen hieß es oft

Zitat:

"Fördert die Programmierung gegen ein Interface statt gegen eine konkrete Implementierung"

Damit kann man rein gar nichts anfangen, wenn man nicht ein Beispiel dazu gesehen hat, wie es gemacht werden sollte und warum alles andere Mist ist. Mitlerweile komm ich da etwas besser rein.

Zitat:

Hier liegt der Fehler. Übergibst du einen Datenbank-Adapter, bleibt dir nichts anderes übrig als direkt Queries zu verwenden. Damit hast du dich fest gebunden. Mit Zend_Db könntest du allerdings Queries generieren, die je nach Zend_Db_Adapter auf alle verfügbaren Datenbanken passen, obwohl sich die Syntax leicht unterscheidet (MySQL, Oracle, SQLite, ..). In dem Thread den ich gepostet habe gehe ich allerdings den umgekehrten Weg. Nicht die User-Klasse holt sich die Daten (denn dann muss sie wissen woher sie kommen), sondern ein Manager füllt ein User-Objekt mit Daten. Dann bleibt dein User-Objekt immer gleich (und frei von Queries), und wenn du die MySQL mal gegen eine Oracle austauscht, wechselst du einfach nur den Manager.

PHP-Code:

  <?php

$manager = $this->_getDefaultUserManager();

$user = $manager->getUser(1);

?>

Hmm, und wo rufst du den Mangager auf?

$this-> deutet ja auf die Verwendung in einer Klasse hin, aber holst du dir den Manager in der Userklasse und wieso sollte dort die Funktion _getDefaultUserManager(); definiert sein? Dann müsste ich ja in jeder Klasse so eine Funktion anbieten die dann _getDefault****Manager lauten und die mir dann den jeweilie Manager zurückliefern würde, nur damit ich mir damit dann ein Userobjekt erzeugen könnte, welches dann auch noch in der Klasse User erzeugt werden würde? Oder hast du dich mit dem $this-> vertan.

Zitat:

Statische Funktionen/Methoden solltest du vermeiden.

Wenn ich doch nur könnte wie ich wollte

Ich weiß ja dass das schlecht und unpraktikabel ist, aber ich wusste leider auch nicht, wie ich es anders machen sollte.

Zitat:

Auf meinen Thread bezogen? Ja so ähnlich. Woher dieser Array dann kommt entscheidest du.

Schön und gut, aber genau da liegt ja mein Problem. Wie kann ich dieses Array elegant und unabhängig von allem anderen holen und genauso elegant und unabhängig weiterverwenden?

Mein Problem ist wohl die Datenschicht. Habe mir das Row-Data-Gateway und das Table-Data-Gateway Pattern angesehen, jedoch werden diese anhand von Propel erklärt, das diese Pattern wohl implementiert, doch ich mag mir nicht extra Propel installieren, sondern ich würde lieber den Aufbau dieses Patterns und die Funktionsweise kennenlernen. Wie die von Propel erzeugte Klasse dann aufgerufen wird interessiert mich so gar nicht

Ich persönlich komme dadurch leider nicht weiter.

Durch meine beiden Klasse aus dem ersten Post habe ich ja eine gewisse Unabhängigkeit geschaffen, denke ich, aber wie du schon sagst, Chriz, ein User sollte, wie alle anderen Objekte anderer Klasse auch, eine Datenbank wohl eher benutzen anstatt eine Spezifizierung zu sein, die ich durch eine Vererbung erhalten habe.

Das Problem ist nur, mir fällt nichts mehr ein und wenn ich dann einen Code oder ein Tutorial wie das von dir finde, finde ich keine einzige Datenbankabfrage. Auch mit dem Code von rudygotya kann ich leider nichts anfangen, das Zend Framework habe ich noch nicht benutzt, vielleicht sollte ich mir mal das APF runterladen und da mal reinschauen?

Es wird leider immer nur vieles erklärt wenn die Daten schon vorliegen, sei es im Array oder sei es das sie über setter gesetzt werden, aber persistent sind die Daten dadurch noch nicht und ich finde einfach keinen vernünftigen Code dazu, von dem ich mir das "Holen der Daten" vielleicht mal abschauen könnte, damit ich es mal selbst umsetzen kann.

So wie ich meinen Code im Moment schreibe, eignet er sich jedenfalls nicht für größere Applikationen!

Naja, ich werde wie gesagt erst mal weiter in meinem Buch blättern, vielleicht kommt die Erleuchtung ja doch noch.

Gruß

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Hilfe: datenbank mappen und kopieren	MIB	Datenbanken	29	15.02.2012 21:55

01.09.2009, 16:13
Asipak Moderator Registriert seit: 18.07.2005 Beiträge: 4.072	Datenbank austauschbar machen durch Trennung von konkreter Implementierung Hallo alle miteinander, vor ein paar Tagen ist mein Buch zum Thema PHP Design Patterns angekommen und ich habe mich damit beschäftigt, eine Datenbank (z.B. MySQL) gegen eine andere (z.B. XML Dateien) leicht austauschbar zu machen. Als Beispiel zur Übung dient mir hierzu eine Klasse User, die ihre Daten von einer Datenbank bekommen soll. Das ganze sah dann zunächst so aus: Konkrete Implementierung › Ablage › ubuntuusers.de Ein Objekt der Klasse User wird jeweils mit einer ID und einem Namen instanziert. Dazu lese ich einmal Daten aus einer MySQL - Datenbank Code: id \| name 1 \| Name1 2 \| Name2 aus und gleich danach kommen die Daten aus einer XML Datei: database.xml PHP-Code: `<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE database PUBLIC "database" "database.dtd"> <database> <user> <id> 1 </id> <name> Name1 </name> </user> <user> <id> 2 </id> <name> name2 </name> </user> </database>` Auslesen der Daten: PHP-Code: $sql = "SELECT `id` , `name` FROM `users` "; $result = mysql_query($sql, $c) OR die (mysql_error()); echo '<h1>MySQL Datenbank</h1>'; while ($row = mysql_fetch_array($result)) { $user = new User($row["id"], $row["name"]); echo '<p>' . $user->getName() . '</p>'; } echo '<h1>XML Datei als Datenbank</h1>'; $data = simplexml_load_file('../xml/database.xml'); foreach ($data->user as $concrete_user) { $user = new User($concrete_user->id, $concrete_user->name); echo '<p>' . $user->getName() . '</p>'; } Das funktioniert natürlich super, aber ich müsste so ja jedesmal die konkrete Implementierung zum Auslesen und Ausgeben der Daten anpassen, wenn ich die Datenbank wechseln möchte. Ich hab mir also angeschaut was gleich ist: Auslesen der Daten und als User-Objekte zurückgeben. Wenn ich die Userobjekte erst einmal habe, bleibt nur noch: PHP-Code: `echo '<p>' . $user->getName() . '</p>';` übrig. Daher habe ich mir ein Interface angelegt, dass von beiden Datenbankklassen erwartet, dass sie eine Funktion bereitstellen, um sämtliche User aus der Datenbank auslesen zu können, damit ich die Benutzer als Objekte zurückerhalte. PHP-Code: `interface UserAdministration { public function getUsers(); public function getUserById($id); }` Das Script sieht mitlerweile so aus: Verwendung von Klassen › Ablage › ubuntuusers.de Der Aufruf und die Ausgabe erfolgt dann so: PHP-Code: `$users = new XML_Database_Users('xml/database.xml'); //$users = MySQL_Database_Users::getInstance(); foreach ($users->getUsers() as $user) { echo '<p>' . $user->getName() . '</p>'; }` Genau das, was ich haben wollte. So brauche ich zumindest nur noch der Variablen $users ein Objekt der Klasse übergeben, die das Interface implementiert und mit der ich die Daten auslesen kann. Ich habe die Klassen abstract class MySQL_Database { und abstract class XML_Database { als abstrakt definiert, da ich von ihnen ja noch weitere Klassen ableiten kann, mit denen ich dann z.B. anstelle von Userdaten, Termine eines Kalenders o.ä. auslesen könnte! Diese würden dann aber wieder ein anderes Interface implementieren müssen. Ich stelle mir gerade vor, dass ich für jede "wichtigere" Tabelle, die ich in einer MySQL-Datenbank habe, eine Klasse von der Klasse MySQL_Database ableiten und jeweils ein neues Interface erzeugen oder ableiten müsste. Ist das ein Schritt in die richtige Richtung oder kann ich mich bald vor Klassen nicht mehr retten? Mir fällt momentan leider keine Idee ein, wie ich die Daten noch weiter zusammenfassen könnte. Vielleicht wenn ich dem Interface eine allgemeinere Bezeichnung verpasse: PHP-Code: `interface DatabaseAdministration { public function getEntries(); public function getEntryById($id); }` ? Ich möchte eigentlich nur wissen, ob ich damit so weiterarbeiten kann oder ob ich doch lieber grundlegend etwas ändern sollte und wenn ja, was? Gruß Geändert von Asipak (01.09.2009 um 16:16 Uhr).


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

01.09.2009, 20:56
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.268	Also Zend_Db_Table (Table-Gateway) mag ich garnicht, abgesehen davon ist eine Komposition wohl sicherlich angebrachter als eine Ableitung, denn ein User ist keine Spezifizierung einer Datenbank, sondern benutzt diese lediglich. Ich habe zum Thema Models unabhängig von der Datenquelle schon einmal eine Art Tutorial geschrieben: http://www.php.de/tutorials/54558-tu...l-und-oop.html (Tutorial: PHP/MySQL und OOP) Ich muss zugeben, die Klassen habe ich mittlerweile bei mir stark überarbeitet, ich muss es demnächst mal aktualisieren. Was aber noch aktuell ist, ist das Konzept an sich. Beim Interface hast du die Problematik, dass Datenbank und XML möglicherweise ganz anders arbeiten und eine gleiche Schnittstelle deswegen nicht immer hinzubekommen ist, bzw. performant hinzubekommen ist. So kann ich beispielsweise auch die Session als Persistenzschicht neben der DB oder einem XML verwenden, und die Session muss auf Performance kaum Rücksicht nehmen (serialize/unserialize sind extrem schnell), bei der Datenbank muss ich aber drauf achten, dass ich bei jeder Änderung nicht das komplette Objekt wieder in der DB aktualisiere, weil das durch Fremdschlüssel etc. möglicherweise einen riesigen Overhead annimmt. Nur wie bringt man das in ein gemeinsames Interface? __________________ "Nuschel ich?" - "Was?"

01.09.2009, 21:37
robo47 Moderator Registriert seit: 03.09.2004 Beiträge: 11.792 PHP-Kenntnisse: Fortgeschritten	Nur mal so semi-topic: Wenn ich solche Ansätze sehe muss ich immer an LINQ denken, gibt dafür zumindest im Ansatz (weis nicht wie weit die sind) was in PHP der geht aber wahrscheinlich noch über dein Interesse hinaus, aber nur um es mal erwähnt zu haben. Damit kann man noch einen Schritt weiter gehen und muss sich nicht direkt um Model-spezifische Methoden kümmern sondern stellt einen sql-ähnlichen Ansatz hin mit dem man auf unterschiedliche Datentypen zugreifen kann, sei es xml, eine sql-datenbank. PHPLinq - LINQ for PHP - Language Integrated Query - Home __________________ robo47.net - Blog, Codeschnipsel und mehr \| Caching-Klassen und Opcode Caches in php \| Robo47 Components - PHP Library extending Zend Framework

02.09.2009, 00:56
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Sonderbares Konzept. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

03.09.2009, 09:13
xm22 Erfahrener Benutzer Registriert seit: 30.07.2008 Beiträge: 1.167 PHP-Kenntnisse: Fortgeschritten	Das Konzept von Chriz habe ich vor einiger Zeit auch übernommen. Das ist besonders dann vorteilhaft, wenn man die Queries des Managers möglichst reduziert. Dann ist der Portierungsaufwand - selbst, wenn es auf einen Webservice oder sonst was geht, sehr gering.

03.09.2009, 09:50
Flor1an da schreibt der ElePHPant Registriert seit: 18.06.2008 Beiträge: 8.903 PHP-Kenntnisse: Fortgeschritten	Irgendwie kommt mir Linq auch komisch vor. Code als String anzugeben wiederstrebt mir irgendwie. Damit lassen sich automatische checks durch den Editor schlecht machen. Auch Refactoring oder sonst was wird schwer ...