nicht angemeldet
echo $begrüßung;
protected static $_instance;
protected static $_db_host;
protected static $_db_user;
protected static $_db_pw;
protected static $_db_name;
protected static $_db_connection;
Bitte private. Das Singleton-Pattern lässt keine Vererbung zu, also braucht es kein protected.
$db=db::db_singleton();
$db->db_set_vars('localhost','root','philz','allethemen');
$db->db_connect();
>
> Das ist mir zu umständlich, ich hätte viel lieber das wenn ich das Singleton erstelle, die Klasse die Zugangsdaten schon hat \_und\_ den Connect vornimmt.
Das hab ich ja schon so vorgeschlagen. Die Methode connect() sollte private sein. Alle Methoden, die einen Connect voraussetzen, rufen connect() auf. connect() baut die Verbindung auf, wenn sie noch nicht steht und ansonsten macht sie nichts. Die Zugangsdaten kann sie sich entweder von Klassenvariablen holen, die ganz am Script-Anfang, also noch vor jeglicher Verwendung von db\_singleton(), gesetzt wurden, oder sie holt sie sich aus einer definierten (z.B. ini-File).
> 2. Das Singleton. Erstelle ich es einmal am Anfang von index.php oder macht das jede Klasse die es benötigt, was dann lazy? wäre?
Du hast das Singleton-Pattern anscheinend noch nicht verstanden. Aus der Sicht der Verwender betrachtet, holt sich jeder nur über die getInstance-Methode die Instanz ab. Er kann damit sofort arbeiten, ohne sich um weitere Initialisierungen oder dergleichen zu kümmern. Aus Klassensicht sorgt getInstance für einen verwendungsfähigen Zustand der Instanz.
Die geöffnete Verbindung gehört nicht unbedingt zum verwendungsfähigen Zustand. Die kann wie schon beschrieben im Hintergrund bei tatsächlichem Bedarf eröffnet werden (lazy connect).
> 3. Wie könnte die Vorabübergabe der Daten stattfinden.
> Generell werden \_alle\_ Settings-Daten in einer settings.php stehen.
Oder eine ini-Datei.
> 4. Dedlfix und Tom ihr errinnert dich denk ich. Ich habe noch eine Tools Klasse und eine Ext.Database Klasse mit Zusatzfunktionen.
> 4.1 \_Was\_ kommt noch in die db-Klasse rein?
Ich würde sie public nur mit den RUDI-Funktionen ausstatten, also Read (SELECT), Update, Delete und Insert. Wenn Bedarf in Sicht ist, kann sie immer noch erweitert werden.
> 4.2 wie würdet ihr mit den beiden anderen Klassen verfahren?
Dazu müsstest du konkreter werden. Bau die Klassen mal als Rumpf auf, so dass man ihre Funktionen erkennen kann.
> 5. Die Frage des Destruktors sehe ich in all den Beiträgen immernoch nicht geklärt.
> Destruktor Ja/Nein?, warum?, rufe ich ihn auf?, wann?, ruft er sich selber auf?
Wenn überhaupt, wird er beim Singleton-Pattern nur automatisch aufgerufen, wenn PHP die Instanz wegräumt. Du kannst gern einen erstellen, der das Schließen der Verbindung vornimmt.
> 6. Wie betreibe ich in dem Fall am besten die Fehlerbehandlung?
Eine Klasse sollte so wenig wie möglich Fremdarbeiten erledigen. Das Schreiben ins Dateisystem erfordert beispielsweise Kenntnisse, wohin geschrieben werden soll. Vollständig behandeln kann die DB-Klasse die Fehler sowieso nicht. Sie weiß ja nicht, was die Verwender für den Fall eines Fehlers konkret vorhaben. Es ist sinnlos, das Logfile mit Meldungen vollzuschreiben, wenn explizit das Auftreten eines Fehlers vorgesehen ist. Es ist kein Logfile-Fehler, wenn ein Benutzer sich mit einer bereits vorhandenen Kennung zu registrieren versucht. Ein Insert mit dieser Kennung scheitert in dem Fall wegen Unique-Index-Verletzung. Man sagt dem Benutzer, dass er einen anderen Namen wählen muss und mehr Aufmerksamkeit benötigt diese Fehlermeldung nicht.
Wenn Fehler beim RUDI auftreten, sollten diese durch Rückgabewert oder Exception weitergemeldet werden. Reagieren und gegebenenfalls Maßnahmen treffen obliegt dem Verwender. Er muss sowieso drauf gefasst sein, dass Fehler auftreten. Einfach weiter machen wird nicht möglich sein, denn dazu fehlen ja die Daten, die man eigentlich dazu benötigte. Also muss ein alternativer Weg gegangen werden und damit hast du eine Fallunterscheidung (oder ein try-catch bei Exceptions).
> Alle Fehler werden an eine extra Fehlerbehandlungsklasse weitergegeben, dort wird eine Variable aus der settings.php abgefragt über den aktuellen Status (a oder b).
Nicht Fehler"behandlungs"klasse sondern eher ein Logging-Mechanismus, der generell verwendet werden kann. Beispielsweise dann wenn ein DB-Klassen-Verwender einen Fehler als log-würdig ansieht.
> a. Alles befindet sich in Entwicklung und auf meinem lokalen Webserver, es werden alle Fehler angezeigt und dick unterstrichen angegeben.
Das kann die Log-Klasse gern machen.
> b. Es wird die Verbindung zur DB überprüft. Ist sie vorhanden, werden die Fehler dort eingetragen. Ist sie nicht vorhanden, wird versucht sie dort nochmal aufzubauen ohne die DB-Klasse. Geht das nicht, werden die Fehler in eine TXT geschrieben oder per E-Mail an mich geschickt.
Auch das wäre eine Möglichkeit, was die Log-Klasse machen könnte.
echo "$verabschiedung $name";