[FloB]

Hallo zusammen,

ich weiß, ich erfinde das Rad neu, aber dabei lernt man ja am besten ..

Also:
Ich möchte eine DB-Klasse schreiben. Dazu habe ich erstmal eine abstrakte Klasse definiert:

PHP-Code:

abstract class database {
  
  private $host;
  private $db;
  private $user;
  private $pass;
  
  private $connection;
  private $result;
  
  const DB_NUM   = 1;
  const DB_ASSOC = 2;
  const DB_BOTH  = 3;
  
  
  public function __construct($host = NULL, $db = NULL, $user = NULL, $pass = NULL) {
    if($host !== NULL) $this->host = $host;
    if($db   !== NULL) $this->db   = $db;
    if($user !== NULL) $this->user = $user;
    if($pass !== NULL) $this->pass = $pass;
    $this->connect();
  }
  
  public function __destruct() {
    $this->disconnect();
  }
  
  
  abstract public function connect();
  abstract public function disconnect();
  
  abstract public function query($query);
  
  abstract public function escapeStr($var);
  
  abstract public function getResult(); // return all results as multi-dimensional array
  abstract public function getRow($as = self::DB_ASSOC); // return result (one row) als one-dimensional array
  abstract public function numRows();
  abstract public function freeResult();
  
  abstract public function errstr();
  abstract public function errnum();
  
  abstract public function conf($var, $value = NULL); // gets $var / sets $var to $value
  
} 


Nun meine Frage: Wie findet ihr die Struktur? Fehlt etwas? Ist etwas unnötig?


MfG,
FloB

[robo47]

$this->connect();
im Konstruktor bringt nicht viel wenn die kompletten parameter nicht übergeben wurden!

Wenn getRow die möglichkeit der entscheidung hat ob assoc, num oder object, dann sollte man das auch bei getResults wählen können ob mein Array mit assoziativen oder numerischen Arrays oder mit Objekten will.

eventuell noch ne methode für affected rows ? oder fasst du das unter num_rows zusammen ?

last-insert-id als methode ? kann man auch via query realisieren ...

nur so als anregungen.

[FloB]

Die "Parameter" werden ja als Klassenattribute gespeichert, connect() greift auf diese zu (wenn man mehrere DB-Verbindungen zu versch. DBs aufbauen will, nimmt man ja eh ein neues Objekt).

DB_OBJ kann ich noch einbauen, dachte mir aber eigentlich, dass Objekte langsamer als Arrays sind .. immer perfomant denken .
Bei getResult() wird noch ein DB_NUM kommen.

affected rows .. hm .. eigentlich schon zusammenfassen .. ich kann ja bei mysql_query() auf true überprüfen, wenn ich affected_rows() nehmen will, anosnten num_rows().

Alles andere ist ja auch per Query möglich.


Aber sonst ist das OK so?

Eine Frage hab ich noch: Wenn ich den Konstruktor der Kindklasse dann aufrufe (z.B. new db_mysql($host, ..)), werden dann die Paramter in der dabase-(Abstraktions-)Klasse gespeichert oder in der Kindklasse?

[dr.e.]

Hallo FloB,

zieh dir mal unter http://christian.zierpflanzenberatun.../apps_core.chm die CHM-Dokumentation und schau dir mal den MySQLHandler an. Vielleicht ist das eine Anregung für dich...

[FloB]

Danke .. kann ich sicher noch was übernehmen, wobei das für meinen Geschmack zu viel Funktionen sind ..

[dr.e.]

Hallo FloB,

zu viele private, oder zu viele öffentliche?

[FloB]

Gute Frage ..

Nun, es ist halt vieles abgedekt, z.B. wird automatisch $_lasetInsertID erzeugt - in den wenigsten Fällen braucht man das ...

[dr.e.]

Hallo FloB,

wenn man doch wiederverwendbare und generische Abstraktions-Schichten designed, muss man alle benötigten Fälle abdecken und das ist hier getan...

[FloB]

Das überzeugt mich - zumindest teilweise .

Werd mal drüber nachdenken.

Danke für deine Hilfe!

[Basti]

In meiner/meinen MySql-Klassen erwartet query() zwei Parameter:

1. die Query mit Platzhaltern (in der ersten Version nur %s, in der zweiten Version benannte Variablen: %id%, %author% etc.);

2. ein Array mit den Werten, die diese Platzhalter ersetzen sollen (im ersten Fall ein indiziertes Array mit den Werten in der richtigen Reihenfolge, im zweiten eben eine assoziatives Array).

wenn du das nicht so machst (bzw. keine andere Lösung findest), musst du ja immer außerhalb der MySQL-Klasse mysql_real_escape_string() verwenden und das ist ja nicht der Sinn einer Kapselung in einer Klasse*). Letztlich geht es ja auch darum, diese Klasse durch beliebige andere SQL-Klassen austauschen zu können. Daher noch drei Punkte:

- Bennene die Klasse nicht "database", sondern Database_MySQL, MySqlConnector, oder sonstwie.
- Schreibe ein Interface IDatabase oder so und lass die Klasse dieses implementieren.
- Erkläre mal, warum die Klasse abstrakt sein soll. Da gibts eigentlich nichts zu erweitern, sondern eher eben durch andere Klassen auszutauschen (MySqliConnector, PdoDatabase etc.).

*) Seh grad, dass du eine Funktion zum Escapen anbietest. Ist dennoch einiges einfacher, wenn die du Query und Werte getrennt übergibst!

Basti

[FloB]

Ich habe eigentlich nur aus dem Grund eine Abstraktionsklasse geschrieben, um den Kon- und Destruktor sowie die Variablen als "private" zu definieren. Alles andere sind ja public's, deswegen werden die eh von den Kindklassen überschrieben.

Ich wollte von Anfang an festlegen, dass eine Verbindung nur anhand der Attribute der Klasse aufgebaut werden kann, also dass die Verbindungsdaten nicht als Parameter für connect() übergeben werden sollen (dürfen).

Meinst du, ich hätte eher ein Interface basteln sollen?

Ich habe mir bei der Planung gedacht, dass es eine Kindklasse mit dem Namen db_sql gibt, die dann entweder PDO nutzt, oder weitere Kindklassen (mit MySQL o.ä.) aufruft.


Eine automatische Behandlung im Query find ich gut, aber manchmal möchte ich nicht unbedingt einen String escapen ...

[Basti]

Zitat von FloB

Ich habe eigentlich nur aus dem Grund eine Abstraktionsklasse geschrieben, um den Kon- und Destruktor sowie die Variablen als "private" zu definieren. Alles andere sind ja public's, deswegen werden die eh von den Kindklassen überschrieben.

Ich wollte von Anfang an festlegen, dass eine Verbindung nur anhand der Attribute der Klasse aufgebaut werden kann, also dass die Verbindungsdaten nicht als Parameter für connect() übergeben werden sollen (dürfen).

Meinst du, ich hätte eher ein Interface basteln sollen?

Die Frage ist halt, was letztlich übrig bleibt. Einer PDO-Klasse übergibst du ja einen String mit den Verbindungsdaten, da kannst du den Konstruktor also schonmal vergessen und die privaten Eigenschaften brauchst du dann letztlich auch nicht. Und, ja, das beenden der Verbindung würde natürlich in eine Basisklasse passen. Je nach Anwendung lässt sich sowas aber auch leicht von außen steuern.

Eine automatische Behandlung im Query find ich gut, aber manchmal möchte ich nicht unbedingt einen String escapen ...

Das ist dann ja kein Problem. Hierzu schreibst du die Werte einfach direkt rein:

PHP-Code:

<?php

class MyDao extends Dao
{
    public function getSomething($iId, $sName)
    {
        $sQuery = "SELECT * FROM `table` WHERE id = $iId AND name = `%name%`";
        return $this->query($sQuery, array('name' => $sName));
    }
}

Basti

[FloB]

Nun, in der connect()-Funktion der Kindklasse db_sql könnte der Verbindungsaufbau mit PDO so aussehen:

PHP-Code:

$conn = new PDO($this->drv.':host='.$this->host.';dbname='.$this->db, $this->user, $this->pass); 


Im Konstruktor werden die Variablen dann definiert.

Privat habe ich die Variablen aus dem Grund definiert, um Sicherheit zu gewährleisten. Wenn jetzt ein 3rd-Party-Modul einfach database::pass ausliest und an den Programmierer schickt, hat der User den Salat.

*TODO: in der Abstraktionsklasse __get() definieren (final) und false zurückgeben / Exception werfen.

[Basti]

Huch? Und wo kommen die Verbindungsdaten her? Was ist mit var_dump()? Was mit den Reflection-Klassen?

Basti

[FloB]

Die Verbindugsdaten werden direkt in die Datei geschrieben - bei der Installation. var_dump() muss ich mir anschauen, denke aber, dass man das per private eben umgehen kann.

Die Reflection-Klassen muss ich mir mal anschauen ..

[dr.e.]

Die Verbindugsdaten werden direkt in die Datei geschrieben - bei der Installation.

Das ist ein Design-Fehler. Verbindungsdaten MUSS man konfigurierbar machen.

[FloB]

Ja - wenn die Datei beschreibbar ist. Diesen Design-Fehler nehme ich in Kauf, solange es der Sicherheit dient.

Natürlich kann man immernoch eine andere Verbindung aufbauen - dazu eine neue Instanz der Klasse anlegen (Verbindungsdaten werden an Konstruktor übergeben, der "ändert" sie). Nur kann man die Standard-Verbindungsdaten nicht erfragen!

[dr.e.]

Hallo FloB,

in "meiner Welt" wird die MySQL-Abstraktions-Schicht mit der Methode $this->__getServiceObject() initialisiert und erhält dabei vom serviceManager automatisch den Context der Applikation. Mit Hilfe dieses Contextes kann die MySQL-Klasse dann die zugehörige Konfiguration für die Verbindungsdaten und andere Einstellungen laden. Da der Context einer Applikation jeweils für den kompletten Objektbaum zentral in der index.php geändert werden kann ist man hier absolut flexibel. Möchte man eine andere Verbindung als die Standard-Verbindung aufbauen, kann man einfach einen neuen MySQL-Treiber mit einem anderen Context erstellen.

Die Möglichkeit über die Änderung der Zugangsdaten im Konstruktor ist zwar niicht verkehrt, jedoch behindert diese Tatsache dich, den Treiber singleton zu instanziieren um z.B. bessere Performance erziehlen zu können.

[FloB]

So firm bin ich in OOP nicht, dass ich alles in deinem Beitrag verstehen würde ..

Ich will nur aus Sicherheitsgründen die (Standard-)Verbindungsdaten in der Klasse privat speichern, sodass ein 3rd-Party-Modul diese nicht auslesen kann und sonst etwas anstellen kann.

Bisher hab ich es so gesehen, dass die DB-Daten einmal eingetragen werden und dann nicht mehr verändert werden - Umstrukturierungen / Umzug sind Ausnahmen.

Aber meint ihr, das wäre egal? Könnte man die Sicherheit irgendwie anders lösen, also praktisch in der Config-Klasse überprüfen, ob die abrufende Klasse eine Instanz von soundso ist? Wie geht das, mit instance_of()?

[robo47]

das klingt ja so, wie wenn du wild-fremden php-code zusätzlich zu deinem laufen lässt. das 3rd-Party-Modul, das deine Daten will um sie weiterzuversenden bekommt sie recht einfach indem es die Datei via fopen öffnet, oder var_dump nutzt oder sonst irgendwas und wenn es was böses in der datenbank machen will, nutzt es einfach die instanz deiner datenbankklasse.