[Stefan125]

Hallo bin gerade etwas am verzweifeln ..
wieso klappt diese tolle klasse denn nicht also das verbinden an sich klappt schon nicht..

PHP-Code:

<?php
class DB_MySQL {
  var $connection = NULL;
  var $result = NULL;
 
   function connect($host, $database, $user, $pass) {
    $this->connection = mysql_connect(
      $host,
      $user,
      $pass,
      TRUE
    );
 
    mysql_select_db($database, $this->connection);
  }
 
   function disconnect() {
    if (is_resource($this->connection)) {
      mysql_close($this->connection);
    }
  }
 
   function query($query) {
    if (is_resource($this->connection)) {
      if (is_resource($this->result)) {
        mysql_free_result($this->result);
      }
 
      $this->result = mysql_query(
        $query,
        $this->connection
      );
    }
  }
 
   function fetchRow() {
    if (is_resource($this->result)) {
      $row = mysql_fetch_assoc($this->result);
 
      if (is_array($row)) {
        return $row;
      } else {
        return FALSE;
      }
    }
  }
}
?>

mit dem folgenden code versuche ich eine verbindung herzustellen...

PHP-Code:

require_once 'class.mysql.php';
 
$mysql = new DB_MySQL;
if(!$mysql->connect('localhost', 'usr_web120_3', 'web120', 'pass'))
    {
        echo 'Error: Mysql Verbindung konnte nicht aufgebaut werden. Überprüfen sie ihre angaben in der Datei: include/mysql.php<br>';
        exit;
    } 


[WarrenFaith]

deine Methode connect() liefert ja nichts zurück, dementsprechend ist deine IF-Abfrage immer false.

Vielleicht eher so?

PHP-Code:

error_reporting(E_ALL); // ganz wichtig um Fehler zu finden!
require_once 'class.mysql.php';
 
$mysql = new DB_MySQL(); // bitte die Klammern nicht vergessen :-)
$mysql->connect('localhost', 'usr_web120_3', 'web120', 'pass');
if(mysql->connection == null) {
   echo 'Error: Mysql Verbindung konnte nicht aufgebaut werden. Überprüfen sie ihre angaben in der Datei: include/mysql.php<br>';
   exit;
} 


[/quote]

[kampfgnom]

oder du überprüfst schon in der klasse und gibst dann true/false zurück!

[Jann Hendrik]

Die von mir benutzte Klasse benötigt keinen expliziten connect-Aufruf.
Dies wird bei einem query der an die db geschickt werden soll asutomatisch nachgehohlt, sofern noch keine Verbindung vorhanden ist.
Dann wird versucht eine solche zu erstellen.
Wenn das nicht gelingt, dann gibt es einen entsprechenden Abbruch.

Der Vorteil, den ich darin sehe ist der, dass man nicht explizit connecten muss. Der Nachteil liegt darin, dass bei jedem query geprüft werden muss, ob die Verbindung noch/schon besteht.

[Basti]

Hi.

Warum übergibst du die Verbindungsdaten nicht einfach im Konstruktor und wirfst eine Exception, falls die Verbindung fehlschlägt. Eine Verbindung on-the-fly würde ich nicht umsetzen, da du die Exception dann bei jeder Abfrage erwarten musst. Eher würde ich das Objekt eben erst bei Bedarf bauen lassen.

Weiter macht es Sinn, ein Ergebnis-Objekt einer Anfrage zurückzugeben, anstatt eine Methode fetchRow() ohne Parameter anzubieten. Funktioniert natürlich, kann aber auch zu Konflikten führen und ist eben keine in sich wirklich stimmige API.

Methoden wie numRows() oder fetchRow() kannst dann in dieses Ergebnis-Objekt verschieben.

Basti

[dr.e.]

Soetwas finde ich grundsätzlich kontraproduktiv, da sich die Anwendung um die Zugangsdaten zur Applikation kümmern muss und man Quellcode ändern muss um eine Applikation z.B. auf einer neuen Umgebung online bringen zu können. Da das variable Daten sind, sollten Verbindungsdaten in ein Config-File. Hier ist es ratsam, der MySQL-Klasse eine Möglichkeit zu geben, ihre Verbindungsdaten an Hand der aktuell eingesetzten Umgebung und der aktuellen Applikation einzulesen. Ich erwarte das so:

PHP-Code:

require_once 'class.mysql.php';
 
$mysql = new DB_MySQL();
$mysql->executeQuery('SELECT bla FROM blub WHERE name = 'hannes);

... 


Alles andere ist jedes Mal so viel Schreibarbeit, dass das eine Applikation / Modul zu sehr aufbläht. Denkt man in Abstraktions-Schichten, so ist alles andere auch Käse.

[Basti]

Zitat von dr.e.

Alles andere ist jedes Mal so viel Schreibarbeit, dass das eine Applikation / Modul zu sehr aufbläht. Denkt man in Abstraktions-Schichten, so ist alles andere auch Käse.

Kann ich nicht nachvollziehen. Zum einen macht es eine Klasse unabhängiger, wenn die Daten im Konstruktor übergeben werden und nicht aus einem Config-Singleton mit definierter API gezogen werden müssen und zum anderen hab ich z.B. meine MySQL-Klasse schon seit Monaten nicht mehr angefasst, oder irgendwo Verbindungsdaten übergeben, obwohl meine Anwendung natürlich auf mehreren Servern mit je mehreren Datenbanken läuft. Das steht also in keinem Widerspruch. Ich arbeite z.B. mit einer DAO-Factory, die einmal die Verbindung baut, sich dazu die Daten aus einem Config-Objekt zieht und diese Verbindung eben bei dem Bau jedes DAO diesem mitgibt.

Basti

[dr.e.]

Ich arbeite z.B. mit einer DAO-Factory, die einmal die Verbindung baut, sich dazu die Daten aus einem Config-Objekt zieht und diese Verbindung eben bei dem Bau jedes DAO diesem mitgibt.

Und wo ist nun der Unterschied zu meiner Beschreibung (ausser natürlich die Begriffe Klasse vs. Factory)?

[Basti]

Zitat von dr.e.

Und wo ist nun der Unterschied zu meiner Beschreibung (ausser natürlich die Begriffe Klasse vs. Factory)?

Na eben darin, dass meine MySql-Klasse ganz leicht wiederverwendbar ist und diese engere Verwurzelung (Abhängigkeit von einem speziellen Config-Interface) erst die DAO-Factory trifft. Ich komm selten in die Verlegenheit, andere Datenbankanwendungen zu programmieren, als mein "Hauptprodukt", aber da finde ich es angenehm, die MySql-Klasse einfach benutzen zu können.

Basti

[Griecherus]

Hallo allerseits. Damit sich niemand wundert, wer sich da zu Wort meldet: Ich bin neu hier, auch wenn ich das Geschehen in dem Forum schon eine kleine Weile mitverfolge.

@dr.e.: Meinst du das im Prinzip so? Oder bin ich auf dem falschen Dampfer?

PHP-Code:

class Database
{
    public function __construct()
    {
        $host     = Configuration::get('database.host');
        $port     = Configuration::get('database.port');
        $username = Configuration::get('database.username');
        $password = Configuration::get('database.password');

        $this->_connect($host, $port, $username, $password);
    }
} 


Denn in dem Fall müsste ich mich Bastis Meinung anschließen. Die Wiederverwendbarkeit der Klasse Database ist - wenn überhaupt - nur eingeschränkt vorhanden. In einer fremden Umgebung müsstest du entweder dafür sorgen, dass eine entsprechende Configurations-Klasse mit genau diesem Interface gegeben ist, oder die Datenbank-Klasse selbst umschreiben.

Grüße,

Jean

[Basti]

Das hier wäre schonmal ein guter Schritt, um die Abhängigkeit transparent zu machen:

PHP-Code:

class Database
{
    public function __construct(IConfig $Configuration)
    {
        $host     = Configuration->get('database.host');
        $port     = Configuration->get('database.port');
        $username = Configuration->get('database.username');
        $password = Configuration->get('database.password');

        $this->_connect($host, $port, $username, $password);
    }
} 


Aber auch so sehe ich keinen wirklichen Vorteil darin gegenüber er Übergabe der Werte als Zeichenketten.

Es sei denn natürlich, die Klasse soll eh nur in der einen Anwendung verwendet werden. Dann wiederum fände ich diese Variante gut, weil die Abhängigkeit zum Konfigurations-Objekt sichtbar ist.

Basti

[dr.e.]

Hallo ihr beiden,

die Transparenz und die Wiederverwendbarkeit schaffe ich anders. Ich erzeuge meine Objekte, die stets von einem zentralen Basis-Objekt erben, mit einigen Informationen zur aktuell ausgeführten Applikation. Jedes Objekt kennt seinen Namespace (Ordner, in dem es abgelegt ist), den Context der Applikation und einige andere Kenner wie z.B. Sprache und Umgebung (Live, Stage, ...). Für genau den Fall der jeweiligen Applikation muss ein Config-File angelegt werden und die Klasse zieht sich mit diesen Kennern per Standard-Config-Interface seine Konfiguration. Das kann ich innerhalb jeder Klasse über die Methode $this->__getConfiguration() machen. Diese zieht sich den ConfigurationManager und bestückt diesen mit den oben genannten Attributen und bekommt dann die jeweilige Config oder null, wenn diese nicht existiert (siehe http://www.adventure-php-framework.o...73fa4bbc767c87).
Diesen Mechanismus kann ich in allen Klassen verwenden und Transparenz und Wiederverwendbarkeit sind ohne Probleme gegeben.

[Basti]

Es geht doch nicht um die Wiederverwertbarkeit innerhalb eines Frameworks. Da kannst du das doch zusammenbacken wie du lustig bist.

Auch geht es nicht um Transparenz im laufenden System, sondern in UML-Diagrammen und API-Dokumentationen ist doch klar.

Basti

[dr.e.]

Auch geht es nicht um Transparenz im laufenden System, sondern in UML-Diagrammen und API-Dokumentationen ist doch klar.

Warum sollte diese Methode nicht transparent sein? Im Konstruktor der Klasse beschreibe ich die Funktion doch. Mit einer geegneten API-Dokumentations-Software (z.B. doxygen) bekommt man sogar einen "call tree" gezeichnet, der dem Benutzer exakt aufzeigt, wo welche Funktion/Methode/Klasse benutzt wird. Nebenbei ist mir nicht bewusst gewesen, dass wir zuvor von UML-Diagrammen sprachen...