PEAR::DB

Josh

Josh

Legendäres Mitglied
hallo alle.

nach wie vor bin ich auf der suche, wie ich meine web apps modularisierter und professioneller gestalten kann. ich habe schon einiges von PEAR gehört und seinen DB funktionen, allerdings habe ich nach einem kurzen tutorial irgendwie den sinn der sache noch nicht so ganz erkannt.

hat wer erfahrung damit und kann mir sagen, was da der grosse vorteil ist?

vielen dank.
smile.gif

josh
 
Ich bin mir nicht sicher und habs auch noch nie genutzt, aber ich denke mal, dass das eine Klasse sein wird ( natürlich mit PEAR-Merkmalen, sprich namensgebung von Variablen etc. ) und man damit unabhängig vom DB-Typen arbeiten kann. Also du gibst an eine Einstellungsmethode den DB-type zurück und der gilt dann für das gesamte Objekt. Bin mir aber nicht sicher, da ich PEAR:
biggrin.gif
B noch nie genutzt habe.
 
Ich denke der Vorteil sollte Datenbankabstrahierung sein (Stichwort db abstraction layer) , d.h. der Aufwand um auf eine andere Datenbankart zu wechseln sollte gering sein. Das ist ja auch einer der Gründe warum Leute Adodb oder phpLib verwenden.

So etwas ist in der Realität dann aber doch recht mühsam, weil die sql-Abfragen selbst eben nicht immer gleich bleiben können. Da sollte man sich schon fragen ob der Aufwand sich lohnt. Da braucht man nur an Datumsfelder denken.

Real sind halt bei den unterschiedlichsten Klassen zusätzliche Funktionen ein Grund sie zu verwenden.

Josh ich glaube das du überhaupt an einer Grundproblematik angelangt bist, einerseits will man den Code oft wieder verwenden können, andererseits will man nicht „Atomraketen“ auf Spatzen abfeuern. Das beginnt schon bei der Frage ob und wie viel man Objektorientiert machen will.
 
danke euch beiden.

@ hatschi:
da ich scripts programmiere, die ich dann übers internet verteilen will, wäre eine solche db abstraktion sehr willkommen, da ich selber nur mit mysql arbeite, aber postgre sql o.ä. nicht ein KO-kriterium sein müsste... werd mir das ganze noch einmal ein bisschen anschauen und ggf. selber etwas solches ausprobieren.
 
Wenn man wirklich grosse Projekte entwickelt, vor allem im Team, wird man sich mit der Zeit erschiessen, wenn man nicht auf Pear aufbaut oder mindestens in dem Stile modularisiert. Wenn du nicht bei jeder neuen Idee alten Code umschreiben musst, sparst du so viel Zeit.

Aber für 08/15 Funktionen ist es mit "Atomraketen geschossen" ;-)
 
Da gebe ich dir grundsätzlich recht, größere Teams & Projekte kann man nicht mit „Spagetti-Code“ betreiben.
Ich kenne aber auch größere Projekte wo man ganz bewusst nicht das ganze Objektorientiert macht. Da hat man sich quasi darauf besinnt das PHP eine Scriptsprache ist, und wenn man Objekte will java/.net verwenden kann. Das sind aber eigentlich immer Projekte die nicht als Open Source irgendwo runterzuladen sind und es sich auch leisten können das man sich erst etwas auskennen muss um damit arbeiten zu müssen.
Abgesehen von der Performance, die wirklich ein Problem sein kann, führt OOP im größeren Stil zu anderen Problemen. Aber jetzt geht mir gleich der Saft am Notebook aus…Fazit viele Wege führen zum Erfolg.
 
@ hatschi:
würd mich jetzt doch noch interessieren, zu welchen problemen oop führen kann. hast du mal wieder saft am notebook?
wink.gif
 
@ error:
bei einem vergleich zwischen hardcoded und oop in php las ich, dass die Performance bei OOP um einiges langsamer war als bei hardcoded. Dies ist aber auch logisch, allerdings weiss ich nicht, ob bei PHP das Einbüssen besonders hoch ist.
 
Also OOP und Performance haben in PHP insoweit etwas miteinander etwas zu tun als das PHP dann einfach langsamer wird.
Lesestoff : http://www.zend.com/zend/art/mistake1.php#Heading13

Ich weiß das soll mit php 5 besser werden, aber bis das mal wirklich in Verwendung ist heißt dauert es wohl schon noch.

Eine Stärke von PHP war/ist das man mit unglaublich wenig Aufwand, im Vergleich zu anderen Sprachen, schnell zu einem Resultat kommt.

Ein Beispiel für ein klassisches Problem bei OOP ist die Vererbung. Oft entstehen da Probleme, entweder weil Änderungen bei "Kindern" nicht mitgenommen werden weil die Methode überschrieben wurde, oder Änderungen führen unerwartet zu Problemen bei "Kindern" weil man beim erstellen nicht bedacht hat wer die Änderung aller Erbt und was das bedeuten kann.

Obiges Beispiel ist aber nicht typisch für eine PHP-Situation, einfach weil die meisten web-Applikation so "simpel" sind das sowieso nichts vererbt wird.

Ich bin nicht für "weg mit oop", sondern dafür das man Kosten/Nutzen von Fall zu Fall betrachtet.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben