[PHP/MySQL] Query Frontcotroller?

S

strolch00

redraft.de
ID: 155297
L
21 April 2006
1.684
72
Hi @all,

also ich gebs zu ich bin ein faules Schwein 8) ,
deswegen habe ich mir gerade überlegt so eine Art Frontcontroler zu basteln für meine SQL Klasse.
Folgende Situation:
Ich habe einen Query aber dort ist ein error, da ich es nun leid bin immer die(ERROR) oder echo ERROR; zu tippen habe ich mir überlegt das ganze doch die Funktion machen zu lassen.
Jetzt ist es aber so das das ganze auch per SQL Injektion gesichert sein soll und da kommt man ja nun mal nicht um func_get_args() rum so wie ich das gesehen habe.

Und jetzt hab ich des Salat:
der Funktionsaufruf sollte so laufen
PHP: 
$class->Query(query anfrage, argumente...., 1/0);
die 1 steht für mysql_error() sehen 0 = nein
Das ganze kann ich aber vergessen weil ich dann umständlich filtern müsste mit func_num_args() um das letzte 1. auszuschließen vom Query und 2. echo ERROR ja oder nein festellen zu können.

Jetzt mein Lösungsansatz:
fuktionsaufruf so
PHP: 
$class->Quest(array/object/query, echo 1/0, SQL, argumente....)
die funktion Quest verarbeitet in der ersten instanz den [0] Schlüssel und ruf die jeweiligen Funktionen auf, [1] echo ERROR ja/nein, und wirft alle argumente sowie das SQL in einen array und übergibt diesen Array (oder das Object) der richtigen funktion(array/object/query).

Jetzt meine Fragen:
Habe ich einen groben Denkfehler um diese Zeit und es geht doch anders?
Seht Ihr Nachteile?
Seht Ihr Vorteile?

ps das mit den Argumenten könnt Ihr sehen an ice_breakers query so in der Art wird es laufen.
Seht von dem deutsch und der Umschreibung einmal ab, bin nimmer ganz aufm Damm.
 
Zuletzt bearbeitet:
strolch00 schrieb:
Seht von dem deutsch und der Umschreibung einmal ab, bin nimmer ganz aufm Damm.
Zum Vergrößern anklicken....
Ich geb mir alle Mühe :biggrin:
strolch00 schrieb:
Habe ich einen groben Denkfehler um diese Zeit und es geht doch anders?
Zum Vergrößern anklicken....
Bezieht sich diese Frage auf die Benutzung von func_get_args() ? Wenn ja, nein, wenn du variable Parameterliste hast, brauchst du diese Funktion.
strolch00 schrieb:
Seht Ihr Nachteile?
Zum Vergrößern anklicken....
Ja.
Ob ein Mysql-Fehler ausgegeben werden soll (eigentlich sollte das ja nie sein, außer zu Debug-Zwecken), interessiert deine Query-/Quest-Funktion doch nicht. Wenn du das stellen willst, sollte das in der Klasse gemacht werden und für jede Query gelten.

Den Parameter, ob du das Ergebnis als Array oder Objekt haben willst, halte ich für überflüssig. Da du dann ja nur noch deine Klasse benutzt, kannst du ja immer mit einer Sorte arbeiten. Ich persönliche benutze nur mysql_fetch_array(), weil sichs mit Arrays eigentlich immer einfacher arbeiten lässt, als mit Objekten.
Ich muss allerdings zugeben, ich hatte mal das Problem, dass ich statt mysql_fetch_array() die Funktion mysql_fetch_assoc() gebraucht hätte, weil mich die numerischen Indezes gestört haben, da musst ich blöderweise mein Ergebnisarray nachbehandeln :-? Also ein Switch kann einen Vorteil bieten, aber ich denke, gesamt gesehen, wird man sowas nicht brauchen und wenn, dann kann man sich ne andere Lösung überlegen.
 
theHacker schrieb:
Ich geb mir alle Mühe :biggrin:
Zum Vergrößern anklicken....
Danke :p

Naja ich wollte es so habe weil ich Das eben nicht in der Klasse haben wollte. Man hat ja auch Situationen wo schon User angemeldet sind oder scripte testen und da ich für meine eigenen Seitn wenig Zeit habe dauert halt auch die Programmierung dem entsprechend. Deswegen würede ich das gern Bei jedem Query sagen können.

Und genau Deine Situation mit dem Assoc hatte ich mir auch überlegt. Deswegen Array/object/query als [0] schlüssel. Weil ich eigentlich immer mit Objekten Arbeite aber auch manchmal Array´s nutze. Ich hatte mal gelesen das objecte in der Hinsicht schneller sind.

Welche Lösungen würden Dir denn einfallen wie man das lösen kann?
 
strolch00 schrieb:
Naja ich wollte es so habe weil ich Das eben nicht in der Klasse haben wollte. Man hat ja auch Situationen wo schon User angemeldet sind oder scripte testen und da ich für meine eigenen Seitn wenig Zeit habe dauert halt auch die Programmierung dem entsprechend. Deswegen würede ich das gern Bei jedem Query sagen können.
Zum Vergrößern anklicken....
ich handhabe das eigentlich immer auf folgendem weg. meine klassen erzeugen grundsätzlich debug-meldungen für alle möglichen events. eine debug-klasse steuert dabei, was und wohin ausgegeben werden soll. ein als admin angemeldeter user kann in der konfiguration einen debug-schalter benutzen. so kannst du dir diverse ausgaben erzeugen lassen auch während andere user auf der seite sind und die ausgabe nicht haben. der schalter ist "frei wählbar", um nur selektive ausgaben anzuzeigen. so gibt es z.b. den schalter DEBUG_MYSQL oder DEBUG_USER etc. die schalter kann man natürlich auch kombinieren. wenn ich in einem laufenden programm nur eine bestimmte ausgabe haben möchte (was wohl deine frage ist), dann setze ich vor dem jeweiligen befehl ein $debug->showNext() ab, was mir immer nur die nächste ausgabe anzeigt, unabhängig vom gesetzten schalter.

ich finde auch, dass debug-ausgaben immer einzeln gehandled werden sollten und nichts in der eigentlichen klasse zu suchen haben. aber genau deshalb hat für mich auch im funktionsaufruf kein debug-schalter irgend etwas zu suchen. wenn mal eine eigene debug-funktion (weil ein bestimmter aufbau notwendig ist) für die klasse vorhanden sein muss, dann steht die natürlich mit in der jeweiligen klasse drin. sie wird aber nur von der debug-klasse gefunden und aufgerufen. nicht von der klasse selbst.

für den laufenden betrieb kann man übrigends einfach die debug-klasse durch ein dummy ersetzen und kitzelt der performance so noch ein paar millisekündchen raus.
 
Also meinst du ich solle mir ne extra debug klasse erstellen und damit würde mein Script aufruf so aussehen.

PHP: 
$debug->SQL();
$class->Quest(array/object/query, SQL, argumente....)

Wenn das so richtig ist, wie handelst du das mit der klasse? Die $debug muss ja irgendwie dann mysql_error() holen, das geht ja aber erst nach dem SQL.
oder ist es so richtig.
PHP: 
$class->Quest(array/object/query, SQL, argumente....) 
$debug->SQL();

dann wären wir wieder bei meinem faulem Schweinehund :LOL:.
Das mit deiner Variante klingt schon verlockend allerding wenn ich so überleg, fällt mir grad keine möglichkeit ein wie ich das einfach realisieren kann, ist vielleicht noch zu früh dafür.
 
strolch00 schrieb:
Also meinst du ich solle mir ne extra debug klasse erstellen und damit würde mein Script aufruf so aussehen.

PHP: 
$debug->SQL();
$class->Quest(array/object/query, SQL, argumente....)
Zum Vergrößern anklicken....

nö, die klasse ist statisch und muss nicht initialisiert werden. ich hab da auch nur drei funktionen drin.

1. trap( $type, $msg, $vars='' ) ... $type ist meist die klasse bzw. das object, welches die meldung ausgibt. $msg ist klar und $vars sind ein paar variablen, objecte oder arrays, die ich zusätzlich per var_export ausgebe bei bedarf ...

2. error_handler ... das ist der eigene error_handler, um notices und errors abzufangen. ist nix besonderes, biegt nur die ausgaben ins debug um.

3. out() ... gibt mir die debug-meldungen aus. ich mach das immer gern so, dass ich einen eigenen layer für alle meldungen habe, der über allem liegt und den ich wegklicken kann. dann wird mir das design nicht zerrissen... wird als shutdown_function registeriert.


wenn du das teil jetzt laufen lässt, dann haben alle klassen bei notwendigen ausgaben einen aufruf in der art (z.b. mysql-klasse): debug::trap( $this, mysql_error(), $query)

debug entscheidet anhand von DEBUG_MYSQL und dem $type-parameter, ob die ausgabe angezeigt werden soll ... wenn ja, dann ab ins array und am ende mit out() ausgeben lassen .

wenn du nur eine einzelne ausgabe anzeigen willst, dann ist DEBUG_MYSQL normalerweise auf false/0 und du rufst vor dem eigentlichen query den debug auf:

PHP: 
Debug::showNext();
$mysql->query( "myquery", $para );

mit showNext wird letztendlich nur dafür gesorgt, dass der nächste aufruf von Debug::trap immer angezeigt wird ... so in der art. hab leider grad keine vorzeigbare version meiner debug-klasse, weil die immer auf das jeweilige projekt zugeschnitten wird und halt sehr nach "debug" aussieht :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben