nicht angemeldet
PHP Objekt
Hallo,
wie kann man denn alle Variablen eines Objektes "resetten"?
Ich habe es mit $objekt = NULL bzw. unset() probiert, aber dabei wird mir auch die Referenz auf das Objekt zerstört. Ich möchte nur die Variablen dieses Objektes auf den Status vor der Initialisierung stellen.
Geht das?
Gruss
Klsoe
-
Hello,
wie kann man denn alle Variablen eines Objektes "resetten"?
Ich habe es mit $objekt = NULL bzw. unset() probiert, aber dabei wird mir auch die Referenz auf das Objekt zerstört. Ich möchte nur die Variablen dieses Objektes auf den Status vor der Initialisierung stellen.Wie wäre es mit einer Methode init()?
Liebe Grüße aus dem Cyberspace
Tom vom Berg
-
Wie wäre es mit einer Methode init()?
Hallo,
ja, das wäre eine Idee. Es geht um folgendes:
das Objekt soll Daten aus einer Datenbank lesen. Das Objekt ist vererbt von einem Datenbankobjekt, welches sich mit der Datenbank verbindet.
Nun stelle ich mir die Frage, ob das sinnvoll ist, dass jede Instanz des Objektes (es sind hunderte) sich für die Abfrage der Daten jeweils wieder neu mit der Datenbank verbindet.
Hab da grad einen Blackout....
Ich wollte es so lösen, dass es nur ein Objekt gibt, welches immer wieder resettet wird und somit die Datenbankabfrage nur einmal durchgeführt wird.
-
Hello,
Wie wäre es mit einer Methode init()?
ja, das wäre eine Idee. Es geht um folgendes:
Du solltest Dich in den Thread https://forum.selfhtml.org/?t=185544&m=1231451 einklinken. Dort habe ich auch einige Links auf Tutorials hinterlassen.
Für Dich würde vielleicht noch
http://www.tonymarston.co.uk/php-mysql/oop-for-heretics.html#each.table.is.a.class passen?Liebe Grüße aus dem Cyberspace
Tom vom Berg
-
Du solltest Dich in den Thread https://forum.selfhtml.org/?t=185544&m=1231451 einklinken. Dort habe ich auch einige Links auf Tutorials hinterlassen.
Danke Tom. Im Grunde gehts mir nur um die Geschwindigkeit. Irgendwie habe ich das Gefühl, als ob eine starke Objektorientierung ziemlich zu Lasten der Performance geht.
muss mal sehn, wie ich das am Besten löse.
Gruss
Klose-
Hello,
Du solltest Dich in den Thread https://forum.selfhtml.org/?t=185544&m=1231451 einklinken. Dort habe ich auch einige Links auf Tutorials hinterlassen.
Danke Tom. Im Grunde gehts mir nur um die Geschwindigkeit. Irgendwie habe ich das Gefühl, als ob eine starke Objektorientierung ziemlich zu Lasten der Performance geht.
Na, dann ist doch die Seite für Ketzer genau die richtige für Dich gewesen :-)
Liebe Grüße aus dem Cyberspace
Tom vom Berg
-
Na, dann ist doch die Seite für Ketzer genau die richtige für Dich gewesen :-)
Ja, das ist genau das, was ich brauche. Allerdings nicht ganz einfach nachzubilden jetzt auf die Schnelle.
Viele grüße
Klose
-
-
echo $begrüßung;
Irgendwie habe ich das Gefühl, als ob eine starke Objektorientierung ziemlich zu Lasten der Performance geht.
Der Performanceverlust ist nicht zwangsläufig stark - wenn man es richtig implementiert. Grundsätzlich bekommt man aber Flexibilität nicht zum Nulltarif. Der Preis dafür ist Komplexität und jeder Code benötigt Laufzeit.
In deinem Fall sehen ich Bedarf für grundlegende Datenbankfunktionalität, die pro Verbindung einmal benötigt wird und Bedarf für spezialisierte Datenklassen, die mehrfach instantiiert werden können, aber alle mit der gleichen Datenbankinstanz reden, um ihre individuellen Daten zu bekommen.
Allerdings sollte das Ganze nicht unbedingt so ausarten, dass jedes Datenklassenobjekt sich selbst seine Daten per individueller Query abfragt. Das geht gehörig zu Lasten der Performance. Dann eher einen Query-Ausführer, der für jedes Element der Ergebnismenge ein Datenobjekt anlegt.
Schau dir auch mal beispielsweise beim Zend Framework die Datengeschichten an. Speziell Zend_Db und Zend_Db_Table sowie Zend_Db_Table_Row. Speziell letzteres ist nicht unbedingt ein Datenobjekt so wie du dir das vielleicht vorgestellt hast, aber vielleicht eine Alternative.
echo "$verabschiedung $name";
-
Hallo,
In deinem Fall sehen ich Bedarf für grundlegende Datenbankfunktionalität, die pro Verbindung einmal benötigt wird und Bedarf für spezialisierte Datenklassen, die mehrfach instantiiert werden können, aber alle mit der gleichen Datenbankinstanz reden, um ihre individuellen Daten zu bekommen.
Danke schonmal für die Antwort. Lass mich kurz zeigen, wie ich das bisher (unzufrieden) gelöst habe:
class db {
//stellt verbindung her, stellt funktionen für query bereit
}class objekt1 extends db{
//holt daten aus datenbank in abhängingkeit von diversen Parametern
}class objekt2 extends db{
//holt daten aus datenbank in abhängingkeit von diversen Parametern
}myo1_1 = new objekt1
myo1_2 = new objekt1
...myo2_1 = new objekt2
myo2_2 = new objekt2
...objekt1 und objekt2 sprechen 2 verschiedene datenbanken an
gruss
Klose-
echo $begrüßung;
class db {
//stellt verbindung her, stellt funktionen für query bereit
}class objekt1 extends db{
//holt daten aus datenbank in abhängingkeit von diversen Parametern
}Ich denke nicht, dass die Klasse objekt1 die Klasse db erweitern muss. Ein Bauer muss auch kein Nachfahre einer Kuh sein, nur weil er diese melken will. Wohl aber muss sich die Kuh in seinem Besitz befinden (er eine Referenz auf sie haben) oder er den Weg zu ihr kennen.
echo "$verabschiedung $name";
-
Hello,
das Problem ist ein ganz anderes: Du versuchst hier nur hohle Wrapper(-Klassen) für bereits vorhandene Funktionalitäten vorzunehmen, diese also nur mit einem anderen Aspekt anzubieten. Das ist aber nicht der Sinn einer Datenbankklasse.
mMn muss eine Datenbankklasse im Webumfeld vor allem diese Dinge bewerkstelligen:
- Allgemeine Bereitstellung der Connectivity zum Datenbankserver und der Datenbank
- Bereitstellung diverser Informationen aus dem Scheme der Datenbank für die Applikation
dazu gehören die Tabellen und ihre Relationen, die Datensatzbeschreibungen der Tabellen - Gewährleistung konkurrierender Zugriffe, insbesonders derjenigen mit Zeitlücke, also das
logische pessimistische Locking oder die Überwachung durch Conflictcounter, Timestamp oder
sonstige gleichwertige Maßnahmen, wenn man es nicht durch Trigger und Stored Procedures
lösen kann (was ich persönlich für sauberer halte) - Verwaltung von vertikalen Zugriffsrechten, , wenn man es nicht durch Trigger und Stored
Procedures lösen kann (was ich persönlich für sauberer halte) - Logging der tatsächlichen Fehlerursachen für die Adminsitration und Bereitstellung von
netten Textchen und Strategien für die Endbenutzerseite - Aufbereitung von Daten für die Übernahmen aus und die Anzeige in HTML (Escaping, Radios,
Checkboxen, Selects, Feldlängenbeschränkungen, Defaults, ...)
Grundsätzlich sollte dabei immer eine Lösung bevorzugt werden, bei der die Aufgaben nicht durch die API, sondern durch die Datenbank (Trigger, Stored Procedures) erledigt werden. Da dies aber nicht bei allen in Webumfeld üblichen DBMS möglich ist, ist es eine schöne Aufgabe[tm] für eine Datenbankklasse.
Alle Zugriffe dürfen dann NUR noch über die Datenbankklasse stattfinden.
Liebe Grüße aus dem Cyberspace
Tom vom Berg
-
echo $begrüßung;
mMn muss eine Datenbankklasse im Webumfeld vor allem diese Dinge bewerkstelligen:
Das soll wohl eine eierlegende Wollmilchsau werden? Wer soll die denn pflegen?
- Allgemeine Bereitstellung der Connectivity zum Datenbankserver und der Datenbank
Keine Frage.
- Bereitstellung diverser Informationen aus dem Scheme der Datenbank für die Applikation
dazu gehören die Tabellen und ihre Relationen, die Datensatzbeschreibungen der Tabellen
Wer's braucht. Normalerweise kennt man ja sein Datenbank-Layout. Es erst erforschen zu müssen geht auf die Performance. Ich sehe das eher als eine zusätzlich Aufgabe für eine andere Klasse.
- Gewährleistung konkurrierender Zugriffe, insbesonders derjenigen mit Zeitlücke, also das
logische pessimistische Locking oder die Überwachung durch Conflictcounter, Timestamp oder
sonstige gleichwertige Maßnahmen, wenn man es nicht durch Trigger und Stored Procedures
lösen kann (was ich persönlich für sauberer halte)
In dem Umfang erfordert das Wissen um das Tabellenlayout beziehungsweise setzt dort bestimmte Felder voraus. Ist aber unter allen Umständen dieser Anwendungsfall gegeben? Nein, sicher nicht. Deshalb sehe ich das als eine Aufgabe einer zweiten Schicht, einer auf eine Datenbank als Speichermedium verwendenden spezialisierten Datenklasse.
- Verwaltung von vertikalen Zugriffsrechten, , wenn man es nicht durch Trigger und Stored
Procedures lösen kann (was ich persönlich für sauberer halte)
Was verstehst du unter Verwalten? Wenn feinere Zugriffsbeschränkungen gelten sollen, als sich mit dem Rechtesystem des DBMS realisieren lassen, wäre das ebenfalls eine Aufgabe der Datenklasse. Oder vielleicht einer dritten Schicht, die sich um Zugriffsbeschränkungen im Allgemeinen kümmert.
- Logging der tatsächlichen Fehlerursachen für die Adminsitration und Bereitstellung von
netten Textchen und Strategien für die Endbenutzerseite
Vom Endbenutzerzeug hat eine Datenbankklasse keine Ahnung. Dafür ist sie in der Struktur zu weit unten angesiedelt. Sie sollte nicht bis nach oben hin durchgreifen können. Und sie muss auch gar nicht wissen müssen, was gerade eben konkret mit diesem Fehler passieren soll. Sie muss nur die Meldung an den Aufrufer weitergeben, ohne sie großartig aufzubereiten. Mitunter ist ein Fehler sogar etwas Erwartetes und eine Meldung anzuzeigen unsinnig.
- Aufbereitung von Daten für die Übernahmen aus und die Anzeige in HTML (Escaping, Radios,
Checkboxen, Selects, Feldlängenbeschränkungen, Defaults, ...)
Das ist Forumlarhandling und überhaupt nicht Aufgabe einer DB-Klasse. Formularhandling ist schon umfangreich genug, wenn man es universell gestalten will.
echo "$verabschiedung $name";
-
Hello,
mMn muss eine Datenbankklasse im Webumfeld vor allem diese Dinge bewerkstelligen:
Das soll wohl eine eierlegende Wollmilchsau werden? Wer soll die denn pflegen?
Das sind ganz typische Anforderungen an die Beschaffung und Manipulation von Daten im Webumfeld und überhaupt nicht so umfangreich, wie Du es glauben machen willst.
- Bereitstellung diverser Informationen aus dem Scheme der Datenbank für die Applikation
dazu gehören die Tabellen und ihre Relationen, die Datensatzbeschreibungen der Tabellen
Wer's braucht. Normalerweise kennt man ja sein Datenbank-Layout. Es erst erforschen zu müssen geht auf die Performance. Ich sehe das eher als eine zusätzlich Aufgabe für eine andere Klasse.
Diese Informationen benötigt man, um die Datenkopplung vornehmen zu können und um die vertikale Kontrolle ausüben zu können.
In dem Umfang erfordert das Wissen um das Tabellenlayout beziehungsweise setzt dort bestimmte Felder voraus.
Genau dies muss die Klasse erzwingen oder erzeugen. Es darf gar nicht möglich sein, Tabellen ohne diese Spalten für die Verwendung im Webumfeld anzulegen.
Ist aber unter allen Umständen dieser Anwendungsfall gegeben?
Ja, er sit immer gegeben, wenn mehr als ein Client gleichzeitig auf die API zugreifen darf.
- Aufbereitung von Daten für die Übernahmen aus und die Anzeige in HTML (Escaping, Radios,
Checkboxen, Selects, Feldlängenbeschränkungen, Defaults, ...)
Das ist Forumlarhandling und überhaupt nicht Aufgabe einer DB-Klasse. Formularhandling ist schon umfangreich genug, wenn man es universell gestalten will.
Nein, das Erstellen des Anzeigeformates ist Sache einer anderen Schicht oder Klasse.
Das Bereitstellen angeforderter Daten und das Anreichern mit weiteren notwendigen Informationen (Defaults, Enum oder Set) ist Sache der Datenbankklasse.
Wieviele Klassen willst Du denn sonst für eine typische Webanwendung erstellen, nur um später in der "Anzeigeklasse" damit z.B. ein <Select>-Element erzeugen zu können, bei Du ja die ausgewählten und die auswählbaren Optionen benötigst. Diese Daten müssen von der Datenbankklasse sofort bei Abfrage bereitgestellt werden und nicht erst später angefordert...
Dies führt dann auch zu der Forderung, dass die Datenbanklasse auf Änderungen im Tabellendesign reagieren können muss, denn sie muss dieses ja nur abfragen und neu aufbereiten, wenn es sich geändert hat, bzw. die Arbeit verweigern, wenn Du gegen Automatismus bist.
Liebe Grüße aus dem Cyberspace
Tom vom Berg
-
echo $begrüßung;
Wieviele Klassen willst Du denn sonst für eine typische Webanwendung erstellen,
Nur die notwendigen für die fachliche Logik. Für den Rest gibt es zur Genüge Frameworks.
nur um später in der "Anzeigeklasse" damit z.B. ein <Select>-Element erzeugen zu können, bei Du ja die ausgewählten und die auswählbaren Optionen benötigst. Diese Daten müssen von der Datenbankklasse sofort bei Abfrage bereitgestellt werden und nicht erst später angefordert...
Du schriebst in dem Stichpunkt "Anzeige in HTML". Das verleitete mich zu der Annahme, dass die DB-Klasse gleich für das Formular oder Teile davon fertige Ergebnisse liefern soll. Du meinst stattdessen, dass sie zu den Feldern nur allgemein den Wertebereich mitliefern soll. - Kann man machen, wenn man den Aufwand treiben will, jedes Mal die Datenbank nach solchen Metadaten zu befragen. Metadaten sind aber nicht an die Datenbankverbindung sondern an die Tabellen gebunden, also an das Datenmodell. Es wäre also Aufgabe eines Tabellenadapters, solche Metadaten zu besorgen, oder besser: gleich zu wissen.
Dies führt dann auch zu der Forderung, dass die Datenbanklasse auf Änderungen im Tabellendesign reagieren können muss, denn sie muss dieses ja nur abfragen und neu aufbereiten, wenn es sich geändert hat, bzw. die Arbeit verweigern, wenn Du gegen Automatismus bist.
Ich bin für eine performante Mischung aus Automatismus und fest kodierter Logik. Wenn ein Fehler auftritt darf die DB-Klasse ihn gern melden. Sie soll robust sein, muss sich aber nicht dem Programmierer gegenüber in Watte gepackt präsentieren.
echo "$verabschiedung $name";
- Bereitstellung diverser Informationen aus dem Scheme der Datenbank für die Applikation
-
Ich denke nicht, dass die Klasse objekt1 die Klasse db erweitern muss. Ein Bauer muss auch kein Nachfahre einer Kuh sein, nur weil er diese melken will. Wohl aber muss sich die Kuh in seinem Besitz befinden (er eine Referenz auf sie haben) oder er den Weg zu ihr kennen.
Vielen Dank, das war deutlich. Ich übergebe jetzt dem Objekt nur noch die Refernz auf das Datenbankobjekt. Und funktioniert und ist schneller als vorher.
Danke für die Hilfe!
-
-
-
-
-
-
-