OOP und PHP - gut oder schlecht?

[glan]

Hallo,
ich hab mal ne Frage nach eurer Meinung.
Und zwar: Ist OOP in PHP sinnvoll? Wenn ja, warum? Wenn nein, warum nicht?

MfG

[Mathias Brodala]

Hallo glan.

ich hab mal ne Frage nach eurer Meinung.
Und zwar: Ist OOP in PHP sinnvoll? Wenn ja, warum? Wenn nein, warum nicht?

Siehe Archiv:

OOP - Einfach Genial oder das letzte was man braucht?[PHP]
Vor- / Nachteile von Objektorientierung

Einen schönen Donnerstag noch.

Gruß, Mathias

[Jonathan]

Hallo,

Und zwar: Ist OOP in PHP sinnvoll? Wenn ja, warum? Wenn nein, warum nicht?

Für sinnvoll halte ich OOP in den meisten Fällen. Allerdings halte ich PHP nicht für die ideale Sprache dafür.

mfg Jonathan

[King^Lully]

ich hab mal ne Frage nach eurer Meinung.
Und zwar: Ist OOP in PHP sinnvoll? Wenn ja, warum? Wenn nein, warum nicht?

M.E. beissen sich RDBMSe und OOP und auch diese Request->Response Geschichte von HTTP scheint mir die avisierte Partnerschaft nicht gerade leicht zu machen.
Die Frage ist auch wie gut PHP OOP unterstützt.

[Christopher]

Hallo,

M.E. beissen sich RDBMSe und OOP

?? Ein Relationales Datenbank Management System ist die zugrunde
liegende Persisiterungsebene, von der bei einer typischen 3 Tier
Anwendung andere Schichten nicht im geringsten abhanegig sein
sollten. Die Business Logik oder gar der Presentation Layer sollten
damit nichts zu tun haben. Im optimalen Falle kann es der Anwendung
sogar absolut Latte sein, was nun mit den Daten geschieht - sie koennen
ja zum Beispiel auch in Form von XML persistiert/serialisiert werden
oder auf Lochkarten gespeichert werden.

und auch diese Request->Response Geschichte von HTTP scheint mir
die avisierte Partnerschaft nicht gerade leicht zu machen.

Das ist nun mal "normal" im Webumfeld. Andere Sprachen bieten jedoch
genau fuer diesen Fall einen Applicationserver an, den ich unter
PHP sehr vermisse. Allerdings kann man sich ja so einen
minimalen Application-Server selber bauen. Eine einfache Version
ist eigentlich recht simpel zu implementieren und bietet bereits
enorme Comfort Vorteile..

Gruesse aus Berlin
Christopher

[King^Lully]

M.E. beissen sich RDBMSe und OOP

?? Ein Relationales Datenbank Management System ist die zugrunde
liegende Persisiterungsebene, von der bei einer typischen 3 Tier
Anwendung andere Schichten nicht im geringsten abhanegig sein
sollten. Die Business Logik oder gar der Presentation Layer sollten
damit nichts zu tun haben. Im optimalen Falle kann es der Anwendung
sogar absolut Latte sein, was nun mit den Daten geschieht - sie koennen
ja zum Beispiel auch in Form von XML persistiert/serialisiert werden
oder auf Lochkarten gespeichert werden.

Verstehe ich nicht. Du siehst keinen Zusammenhang zwischen RDBMS und OOP? Aber gut, ein Beispiel: Du pflegst Kundendaten, Du kommst mit einem Objekt Kunde, das auf mehreren Tabellen des RDBMS (bspw. "Kunde", "Adresse", "Verträge" etc.) basiert.

[Christopher]

Hallo King^Lully,

Verstehe ich nicht. Du siehst keinen Zusammenhang zwischen RDBMS
und OOP?

Nein, nicht im geringsten. Wie ich bereits erwaehnte, die
Anwendungsschicht sollte im optimalen Falle gar nichts davon
wissen, wohin die Daten letztendlich persistiert werden.

Aber gut, ein Beispiel: Du pflegst Kundendaten, Du kommst mit einem
Objekt Kunde, das auf mehreren Tabellen des RDBMS (bspw. "Kunde",
"Adresse", "Verträge" etc.) basiert.

OK, gehen wir mal auf das Beispiel ein.
Das Objekt Kunde besitzt also die weiteren Referenzobjekte Adresse und
Vertraege:

|- Objekt Kunde
  |- Referenzobjekt Adresse (1:1)
  |- Referenzobjekt Vertraege (1:n)

Das Objekt Kunde besitzt eine Save()-Methode. Moechte ich einen Kunden
persistieren, wuerde ich also kunde.Save() aufrufen. Die Methode selbst
wuerde dafuer sorgen, dass nicht nur die Daten des Kunden, sondern auch
saemtliche Referenzen (so fern dies noetig ist) des Kunden persistiert
werden (da jedes Referenzobjekt selbst auch eine Save-Methode besitzt).
Die ganze Logik wird von der Persistenzschicht geregelt und kann wunderbar
mittels eines Codegenerators (welcher anhand der Datenbank-Constraints oder
aber einer einfachen Konfigurationsdatei die Abhaengigkeiten erschließt
und die POs erstellt) generiert werden. Ob Lochkarten, XML oder Datenbank
ist somit egal.

Wirf mal ein Blick auf zB Hibernate, dann wird einem das sicherlich besser
deutlich als anhand meines mageren Beispieles.

Gruesse aus Berlin
Christopher

[King^Lully]

Aha, Missverständnis geklärt, Du willst die gesamte Datenstruktur in der Programmlogik halten, gelegentlich wird dann ein "Kunde.Save()" rausgehauen. Das nötige SQL wird hübsch gekapselt und die Kenntnis desselben spielt für den Entwickler der Geschäftslogik keine Rolle.

So weit, so breit. Dummerweise gibt es diese Unabhängigkeit in der Praxis nicht, es muss immer brav nachSQLt werden, wenn an den Geschäftslogikobjekten etwas geändert wird.

Zudem, und das ist jetzt mein Hauptargument gegen RDBMS+OOP, muss eine neue Schicht eingezogen werden. Dieses ist aufwendig in Erstellung und Pflege, zudem oft einfach doppelt gemoppelt (wenn die Persistierung der Objekte bspw. nur auf einem System (einem RDBMS) erfolgt und nicht auf mehreren).

[Christopher]

Hallo,

Aha, Missverständnis geklärt,

Dafuer hakt es jetzt bei mir ;-)

Du willst die gesamte Datenstruktur in der Programmlogik halten, gelegentlich wird
dann ein "Kunde.Save()" rausgehauen. Das nötige SQL »» wird hübsch gekapselt und die
Kenntnis desselben spielt für den Entwickler der Geschäftslogik keine Rolle.

Richtig.

So weit, so breit. Dummerweise gibt es diese Unabhängigkeit in der Praxis nicht, es
muss immer brav nachSQLt werden, wenn an den Geschäftslogikobjekten etwas geändert wird.

Ich vergaß, reden wir jetzt ueber einen spezielle Fall oder ueber Schichten an sich?
Im letzteren Falle existieren ja extra 3 Schichten, damit die Geschaeaftslogik unabhaengig
von den darunter liegenden Schichten ist.

Zur Veranschaulichung hier einmal die Schichten, von denen ich die ganze Zeit rede:

1. PO's (Persistenzobjekte)
Besitzen das Mapping der Datenbank zu Objekten - so wie Persistierungsfunktionen (Retrieve,
Select, Update, Insert)

2. PA's (Persistenz-Adapter)
Hier findet die Abstrahierung des jeweiligen PO's statt. Variablen/Objekte koennen geaendert,
Validitaetspruefungen implementiert und die Objekte erweitert werden.

3. BO's (Business-Objekts)
Hier findet die eigentliche Geschaeftslogik statt.

Zudem, und das ist jetzt mein Hauptargument gegen RDBMS+OOP, muss eine neue Schicht
eingezogen werden. Dieses ist aufwendig in Erstellung und Pflege, zudem oft einfach
doppelt gemoppelt (wenn die Persistierung der Objekte bspw. nur auf einem System
(einem RDBMS) erfolgt und nicht auf mehreren).

Naja, das ist Geschmackssache ;-)

Gruesse aus Berlin
Christopher

[King^Lully]

Ich vergaß, reden wir jetzt ueber einen spezielle Fall oder ueber Schichten an sich?

Die Sache wird jetzt für meinen Geschmack etwas abstrakt und steht nicht mehr im Kontext PHP. Ich werde jetzt noch ein wenig erläutern und mich dann vermutlich aus der Diskussion - sollte es denn eine geben - zurückziehen.

Wir reden über die Schicht, die entstehen würde, wenn wir den Datenzugriff kapseln. Dieses ist nach meiner Kenntnis mit PHP nicht ohne weiteres zu machen, aber stellen wir uns mal vor es ginge (es geht zwar nicht wirklich, wie MS mit DAO und ADO bewiesen hat), dann wäre die Frage, ob die Schicht erforderlich ist. Die Antwort - den normalen fleissigen Durchschnittsfragesteller hier berücksichtigend - dürfte lauten: Lass die Finger davon!

1. PO's (Persistenzobjekte)
   Besitzen das Mapping der Datenbank zu Objekten - so wie Persistierungsfunktionen (Retrieve,
   Select, Update, Insert)

2. PA's (Persistenz-Adapter)
   Hier findet die Abstrahierung des jeweiligen PO's statt. Variablen/Objekte koennen geaendert,
   Validitaetspruefungen implementiert und die Objekte erweitert werden.

Wenn Objekte geändert werden, ist dann eine Bindung da, die den SQL-Code im Hintergrund anpasst? Wie zuverlässig ist ggf. diese Bindung? Wieviel muss der Entwickler wissen, um im Hintergrund brauchbar generierten Code zu erhalten? Wie oft kommt es zu inperformanten Code? Welche Grenzen hat die o.g. Bindung ggf. (welche Grenzen beim Design im PA bspw.)? Wird vielleicht doch "SQL-direkt"-mässig aus den Objekten immer heraus immer wieder bspw. mal eine SP aufgerufen (weil es eben nicht anders geht)?

Es wäre eventuell hilfreich, wenn Du auf ein Beispiel im Web verweisen könntest, ich würde mir das mal anschauen i.p. Limitierung.
Ich denke aber schon, dass klargeworden ist, warum ich der Meinung bin, dass sich RDBMSe und OOP beissen.

[Christopher]

Tach,

Die Sache wird jetzt für meinen Geschmack etwas abstrakt und steht
nicht mehr im Kontext PHP. Ich werde jetzt noch ein wenig erläutern
und mich dann vermutlich aus der Diskussion - sollte es denn eine
geben - zurückziehen.

OK, in Anbetracht dessen faellt meine Anwort jetzt auch kuerzer aus ;-)

Wir reden über die Schicht, die entstehen würde, wenn wir den Datenzugriff
kapseln. Dieses ist nach meiner Kenntnis mit PHP nicht ohne weiteres zu machen,
aber stellen wir uns mal vor es ginge (es geht zwar nicht wirklich, wie MS mit
DAO und ADO bewiesen hat), dann wäre die Frage, ob die Schicht erforderlich ist.
Die Antwort - den normalen fleissigen Durchschnittsfragesteller hier
berücksichtigend - dürfte lauten: Lass die Finger davon!

Das Konzept ist ja sprachunabhaengig und kann sowohl unter ASP, Java als auch PHP
implementiert werden.

Wenn Objekte geändert werden, ist dann eine Bindung da, die den SQL-Code im Hintergrund
anpasst?

Nein, denn natuerlich bleibt ein Objekt Auto immer ein Auto, daraus wird nie ein Objekt
Stuhl werden.

Wie zuverlässig ist ggf. diese Bindung? Wieviel muss der Entwickler wissen, um
im Hintergrund brauchbar generierten Code zu erhalten?

Fuer das SQL gibt es in diesem Model eine Beschreibungssprache (meisst XML) - anhand dessen
das SQL entweder dynamisch generiert oder aber direkt aufgerufen wird.

Wie oft kommt es zu inperformanten Code?

Hehe, so oft wie in jedem anderen beliebigen Code auch ;)

Welche Grenzen hat die o.g. Bindung ggf. (welche Grenzen beim Design im PA bspw.)?

Beispiel Datenbankspaltenaenderungen:
Spaltenaenderungen in der Datenbank muessen natuerlich nachtraeglich generiert werden.
(Hierfuer gibt es das Konzept der "Unterstrichklassen": _KundePO und KundePO - wobei sich
KundePO von _KundePO ableitet. Die Klassen mit den Unterstrichen duerfen nicht angepasst
werden, da diese durch neue Generierungen ersetzt werden. Dem KundenPO tut dieses nichts,
denn es leitet sich ja von _KundePO ab und besitzt somit automatisch die neuen Spalten).

Wird vielleicht doch "SQL-direkt"-mässig aus den Objekten immer heraus immer wieder bspw.
mal eine SP aufgerufen (weil es eben nicht anders geht)?

Das verstehe ich jetzt nicht..

Es wäre eventuell hilfreich, wenn Du auf ein Beispiel im Web verweisen könntest, ich
würde mir das mal anschauen i.p. Limitierung.

Ich glaube du hast eine falsche Vorstellung von dem, was ich hier versuche zu vermitteln ;)
Um im Web zu bleiben.. ein gutes Beispiel ist zB NHibernate! Das ist das .NET Derivat
von dem bewaehrten Hibernate unter Java.

Ich denke aber schon, dass klargeworden ist, warum ich der Meinung bin, dass sich
RDBMSe und OOP beissen.

Leider immer noch nicht ;-( Denn es werden doch im professionellen Umfeld saemtliche
Geschaeftsprogramme mittels RDBM persistiert. Und ohne OOP sind Programme wie zB. ein
Fuhrparkservice m.M.n. schir nicht moeglich (klar, nichts ist _unmoeglich_, but..).
Von daher kann ich deine Aussage leider nicht nachvollziehen.

Gruesse
Christopher

[King^Lully]

Wenn Objekte geändert werden, ist dann eine Bindung da, die den SQL-Code im Hintergrund
anpasst?
Nein, denn natuerlich bleibt ein Objekt Auto immer ein Auto, daraus wird nie ein Objekt
Stuhl werden.

Die Bindung zwischen dem Objekt "Auto" in der Geschäftslogikschicht und dem Objekt "Auto" in der Datenzugriffsschicht war gemeint. Also, wenn ich bspw. die Einstellung "Auto kann auch 3 Räder haben" dem Geschäftslogikobjekt beifüge, wird dann in der Datenschicht ein entsprechender CONSTRAINT eingestellt?
Muss man das selbst machen?

Wie zuverlässig ist ggf. diese Bindung? Wieviel muss der Entwickler wissen, um
im Hintergrund brauchbar generierten Code zu erhalten?
Fuer das SQL gibt es in diesem Model eine Beschreibungssprache (meisst XML) - anhand dessen
das SQL entweder dynamisch generiert oder aber direkt aufgerufen wird.

Wie gut klappt das? Bestimmte Datenänderungen erfordern bspw. UPDATEs in drei veschiedenen Tabellen und mehrere vorhergehende SQL-Abfragen, die bspw. einen komplexen fünffach JOIN beinhalten.

Wie oft kommt es zu inperformanten Code?
Hehe, so oft wie in jedem anderen beliebigen Code auch ;)

Ich meinte den SQL-Code, der vom framework erstellt wird. Da kann mir keiner erzählen, dass der so gut ist wie bspw.der Lully-gemachte.

Wird vielleicht doch "SQL-direkt"-mässig aus den Objekten immer heraus immer wieder bspw.
mal eine SP aufgerufen (weil es eben nicht anders geht)?
Das verstehe ich jetzt nicht..

Nun, die Frage war, ob in der Praxis immer wieder direkt SQL-Code abgeschickt werden muss, der eigentlich nicht ins OOP-Konzept passt. Weil es nicht anders geht, aber benötigt wird, brauchst Du Beispiele?

Ich glaube du hast eine falsche Vorstellung von dem, was ich hier versuche zu vermitteln ;)

Ich glaube nicht, dass qualitativ guter SQL-Code am Ende dabei herauskommt. Ich glaube, dass es viele Limitierungen gibt. Darum wäre ein Beispielprojekt incl. Code nicht schlecht, das ich mir mal anschauen werde. Vermutlich kann ich dann auch die Kritik detailliert festmachen.

Ich denke aber schon, dass klargeworden ist, warum ich der Meinung bin, dass sich
RDBMSe und OOP beissen.
Leider immer noch nicht ;-( Denn es werden doch im professionellen Umfeld saemtliche
Geschaeftsprogramme mittels RDBM persistiert. Und ohne OOP sind Programme wie zB. ein
Fuhrparkservice m.M.n. schir nicht moeglich (klar, nichts ist _unmoeglich_, but..).
Von daher kann ich deine Aussage leider nicht nachvollziehen.

Du kannst alleine mit den Mitteln der DB (ein geeignetes RDBMS vorausgesetzt) Systeme effizient schreiben, die hochkomplex sind, zuverlässigst laufen und vglw. einfach umgesetzt sind. Dazu nimmt man noch ein wenig PHP oder Perl oder ASP für Darstellung und Dialog und gut ist. (Man kann natürlich auch gleich XML aus der DB kommen lassen und einen Style darauf legen, wenn man moderner eingestellt ist.)

[Christopher]

Hallo King,

ich merke, wir werden morgen frueh noch diskutieren ;)

Die Bindung zwischen dem Objekt "Auto" in der Geschäftslogikschicht und dem Objekt "Auto"
in der Datenzugriffsschicht war gemeint. Also, wenn ich bspw. die Einstellung "Auto kann
auch 3 Räder haben" dem Geschäftslogikobjekt beifüge, wird dann in der Datenschicht ein
entsprechender CONSTRAINT eingestellt?

Fuer die Aenderunge "3 auf 4 Raeder" bedarf es sicherlich keiner Constraints.
Vielleicht hast du nicht gerade ein gutes Beispiel gewaehlt, jedoch lese ich zwischen den
Zeilen wieder eine Vermischung der Persistenzschicht und der Businessschicht.

Wie gut klappt das? Bestimmte Datenänderungen erfordern bspw. UPDATEs in drei veschiedenen
Tabellen und mehrere vorhergehende SQL-Abfragen, die bspw. einen komplexen fünffach JOIN
beinhalten.

Das klappt eigentlich ziemlich gut. Und JOINs sind ja jetzt auch nicht so Komplex, dass man
sie nicht wohl definieren und damit auch konfigurieren kann.

Ich meinte den SQL-Code, der vom framework erstellt wird. Da kann mir keiner erzählen,
dass der so gut ist wie bspw.der Lully-gemachte.

Ich kenne deine Kenntnisse jetzt natuerlich nicht und will dir deine Faehigkeiten auch nicht
abstreiten, aber der Code ist schon ziemlich sauber und optimiert.
Ich meine, Wir reden hier von einem in der Geschaeftswelt eigentlich als Standard etablierten
Persistenz-Framework. Der manuelle Weg ist eindeutig fehleranfaelliger.

Nun, die Frage war, ob in der Praxis immer wieder direkt SQL-Code abgeschickt werden muss,
der eigentlich nicht ins OOP-Konzept passt. Weil es nicht anders geht, aber benötigt wird,
brauchst Du Beispiele?

Ja, zeige mir bitte ein SQL-Code, der "nicht ins OOP-Konzept passt". Ich wuerde gerne
mal verstehen worin du Probleme siehst, die Millionen Entwickler nicht sehen ;-)

Ich glaube nicht, dass qualitativ guter SQL-Code am Ende dabei herauskommt.

Wie bereits oben erwaehnt, Hibernate ist DAS Persistenzframework schlechthin, was bereits seit
ein paar Jahren den Ruf "professionell" fuer sich beansprucht und eben auch in solch
einem Umfeld Verwendung findet.

Ich glaube, dass es viele Limitierungen gibt.

Was meinst Du mit Limitierungen? Selbst Sachen, die auf Code-Ebene geschehen, wie zB Late-Bidings,
lassen sich munter konfigurieren.

Darum wäre ein Beispielprojekt incl. Code nicht schlecht, das ich mir mal anschauen werde.
Vermutlich kann ich dann auch die Kritik detailliert festmachen.

Suche einfach mal bei Google, dort wird man fuendig.

Wir bei uns in der Firma (wir implementieren die Client und Server-Software und -Architektur fuer
den Fuhrparkservice der Deutschen Bahn) nutzen ausschließlich Hibernate (Java) fuer die Persistenzschicht.
Fuerwahr ist Hibernate nur ein Baustein des gesammeten Frameworks, jedoch wird keine einzige Zeile
SQL per Hand implementiert (OK, zu 95% ;) - und das bei Datenbanken >500 Tabellen und unzaehligen
Abhaengigkeiten und Constraints. Vielleicht liegt es genau daran, dass ich deine Einstellung nicht teilen kann.

Bitte nichts fuer ungut, aber ich verstehe ehrlich gesagt nicht,
warum wir jetzt tatsaechlich ueber die Sinnhaftigkeit eines
Persistenzfraemworkes debatieren, wobei die Verwendung eines Solchen
in der Informatik Gang und Gebe, so wie ein sehr verbreitetes und
genutztes Konzept ist.

[King^Lully]

Bitte nichts fuer ungut, aber ich verstehe ehrlich gesagt nicht,
warum wir jetzt tatsaechlich ueber die Sinnhaftigkeit eines
Persistenzfraemworkes debatieren, wobei die Verwendung eines Solchen
in der Informatik Gang und Gebe, so wie ein sehr verbreitetes und
genutztes Konzept ist.

Ich halte nichts von diesen "Persistenzframeworks", das ist alles. Kommt schlechter SQL-Code raus, doppelt gemoppelt und für Otto Normalentwickler einerseits Overkill, anderseits Fehlerquelle. Mag aber sein, dass bei sehr grossen Projekten eine Modellierungsschicht, die über das, was das RDBMS kann, herausgeht, erforderlich ist. Dasselbe kann für SpezialSW gelten, die über VerwaltungsSW weit hinausgeht.

"Programmierst Du noch oder modellierst Du schon?" war mal der hirnrissige Titel eines JAVA-Vortrags, den ich zu mir genommen habe:
Etwas "Klicki", dann "Publizieren" (oder so äähnlich hiess das - d.h. einerseits die DB wurde aufgebaut, anderseits wurde eine webbasierte Standardoberfläche für CRUD kreiert) und der Programmierer hats gebracht, wurde suggeriert. (Nebenbei wurde noch nahegelegt, dass man so "bis zu 60% Quellcode" spart und zudem auch döfere Programmierer billig einkaufen kann.   LOL)
MS und deren "regional directors" halten ganz ähnliche Vorträge, aber die JAVA-Kollegen sind wohl schon weiter.   ;)

[Christopher]

Hallo,

Ich halte nichts von diesen "Persistenzframeworks", das ist alles.

Das ist doch mal eine Aussage ;-)

Kommt schlechter SQL-Code raus, doppelt gemoppelt und für Otto
Normalentwickler einerseits Overkill, anderseits Fehlerquelle.

Um das beurteilen zu koennen, bedarf es meiner Meinung nach jedoch
mehr als die Erfahrungen des Hören-Sagens.

Mag aber sein, dass bei sehr grossen Projekten eine
Modellierungsschicht, die über das, was das RDBMS kann,
herausgeht, erforderlich ist. Dasselbe kann für SpezialSW gelten,
die über VerwaltungsSW weit hinausgeht.

"Programmierst Du noch oder modellierst Du schon?" war mal der
hirnrissige Titel eines JAVA-Vortrags, den ich zu mir genommen habe

Wie wir beide bereits bemerkten, haben wir andere Ansichten was
dieses Thema anbelangt. Doch die oben genannte Frage trifft es
genau. Eine gut ueberdachte Modellierung eruebrigt sehr viel
redundanten Code und erleichtert das Arbeiten exponentiell.

Aber, da gebe ich dir vielleicht recht, in kleineren Projekten
ist es vielleicht ein wenig overkilled - doch es ist wie beim
Sex: hat man es einmal gemacht, mag man nie mehr darauf verzichten ;)

Gruesse
Christopher

[King^Lully]

"Programmierst Du noch oder modellierst Du schon?" war mal der
hirnrissige Titel eines JAVA-Vortrags, den ich zu mir genommen habe
Wie wir beide bereits bemerkten, haben wir andere Ansichten was
dieses Thema anbelangt. Doch die oben genannte Frage trifft es
genau. Eine gut ueberdachte Modellierung eruebrigt sehr viel
redundanten Code und erleichtert das Arbeiten exponentiell.

Es gibt dazu das Äquivalent "MS Frontpage und Konsorten", darauf schwören auch viele, andere finden das generierte HTML&Co nicht so toll. Während ich zu "MS Frontpage und Konsorten" noch ein gemischt positives Verhältnis (ist ja nur das Frontend, was da ggf. ein wenig verhunzt wird) habe, habe ich von dem Gefrickel mit ADO, DAO und die Jungs aus dem "Programmierst Du noch oder modellierst Du schon?"-Lager einen gemischt negativen Eindruck.

Hast Du Dir eigentlich mal angeschaut, was da an SQL DDL- und DML-mässig so rauskommt? (Wenn Du - wie oben angedeutet - bspw. nicht glaubst, dass man die Anzahl der zulässigen Räder eines Autos per geeigneten CHECK-Constraint bearbeitet, kommen mir da so meine Zweifel. ;)

[Christopher]

Es gibt dazu das Äquivalent "MS Frontpage und Konsorten", darauf schwören auch viele,
andere finden das generierte HTML&Co nicht so toll. Während ich zu "MS Frontpage und Konsorten"
noch ein gemischt positives Verhältnis (ist ja nur das Frontend, was da ggf. ein wenig verhunzt
wird) habe, habe ich von dem Gefrickel mit ADO, DAO und die Jungs aus dem "Programmierst Du noch
oder modellierst Du schon?"-Lager einen gemischt negativen Eindruck.

Bei allem Respekt, du redest jetzt von GUI wo wir doch ueber 3-Tier reden?
Wie gesagt, sieh das ganze mal ein wenig abstrakter und nicht aus der PHP-Script-Brille.

Hast Du Dir eigentlich mal angeschaut, was da an SQL DDL- und DML-mässig so rauskommt? (Wenn Du -
wie oben angedeutet - bspw. nicht glaubst, dass man die Anzahl der zulässigen Räder eines Autos
per geeigneten CHECK-Constraint bearbeitet, kommen mir da so meine Zweifel. ;)

Klar laesst sich das ueber Constraints loesen, doch in solch einem maginalem Falle bildet man das
sehr wahrscheinlich lediglich uber eine ForeignKey (-Constraint) ab, welcher auf eine Tabelle a la
WHEELS verweist. Und damit waeren wir wieder bei den Referenz-Objekten. (Klar, fuer diesen Fall gibt
es noch weitere Loesungen..)

Und was deine Zweifel angeht.. bevor du ueber mich zu urteilen vermagst, beschaeftige dich doch bitte
erstmal ausgiebig mit dem Thema. Denn wenn einem der Begriff 3-Tier nicht einmal etwas sagt, dann
ist es mit dem Verstaendnis dafuer logischerweise auch weit entfernt - was jetzt nicht als Vorwurf
auszulegen sein soll.

So, bitte fasse das jetzt nicht falsch auf, doch ich beende jetzt unsere Diskussion. Es erscheint mir
zu sinnlos auf Argumente wie "Der Code von Hibernate ist niemals so gut wie meiner" argumentativ
reagieren zu muessen. Wie gesagt, beschaeftige dich mit dem Thema dann koennen wir die Diskussion
gerne weiter fuehren. Denn an so etwas bin ich stets interessiert.

Gruesse aus Berlin,
Christopher

[King^Lully]

Hast Du Dir eigentlich mal angeschaut, was da an SQL DDL- und DML-mässig so rauskommt? (Wenn Du -
wie oben angedeutet - bspw. nicht glaubst, dass man die Anzahl der zulässigen Räder eines Autos
per geeigneten CHECK-Constraint bearbeitet, kommen mir da so meine Zweifel. ;)
Klar laesst sich das ueber Constraints loesen, doch in solch einem maginalem Falle bildet man das
sehr wahrscheinlich lediglich uber eine ForeignKey (-Constraint) ab, welcher auf eine Tabelle a la
WHEELS verweist.

Nun, "Wheels" könnten natürlich als Entität verstanden werden, ein Autoproduzent hätte damit sicherlich einige vor, ein Leasinggeber wohl eher nicht, der würde vielleicht mit einem CHECK-Constraint kommen.

Auf meine Frage nach der Qualität des automatisch generierten SQL-Codes mit dem Hinweis zu antworten, ich beschäftige mich nicht 3-tier Architekturen, finde ich schon ziemlich lau.

[Christopher]

Lieber Koenig Lully,

Auf meine Frage nach der Qualität des automatisch generierten SQL-Codes mit dem
Hinweis zu antworten, ich beschäftige mich nicht 3-tier Architekturen, finde ich
schon ziemlich lau.

Du magst ja Glanzleistungen vollbringen im HTML/CSS/PHP-Umfeld - das moechte ich ja
gar nicht abstreiten - doch was Themen wie Software-Architektur (Informatik Grundkurs)
und Software-Design (nein, nicht css!) angeht, so musst du dir eingestehen, dass es
dort bei dir noch an Wissen mangelt. Das ist ja auch gar nicht schlimm - doch fuer
dich scheint es das wohl zu sein...

Und bezeuglich meiner lakonischen Antwort:
Stell dir das doch mal bitte aus meiner Sicht vor! Einer, der noch nie etwas von Persistenzframeworks
gehoert hat, versucht tatsaechlich zu behaupten, dass a) der SQL-Code Mist ist, dass b) der Code
redundant sein wird und das c) ein Framework per se fuer die Persistenz unnoetig ist.
Nun frage ich dich: Warum verwendet weltweit jedes mehr oder weniger groessere Projekt bloss
ein Framework fuer die Persistenz? Nur weil es in deinen PHP-Gaestebuechern vielleicht "overkilled" *
ist, schliesst es die allgemeine und professionelle Nutzung doch nicht aus! Schau doch mal ein
wenig ueber den Tellerrand - das ist doch genau das Argument was ihr SelfHTMLer hier staendig anderen
um die Ohren schmeisst!

* obwohl es laut Tim ja bereits Einzug in selbst recht einfach gehaltene Web-Frameworks findet.

[King^Lully]

Wie gesagt, beschaeftige dich mit dem Thema dann koennen wir die Diskussion
gerne weiter fuehren. Denn an so etwas bin ich stets interessiert.

Ich wusste doch, dass da was war, Du bist ein am Forum Leidender, interessante Pathologie:
http://forum.de.selfhtml.org/archiv/2007/3/t147904/#m959273
(Da war wieder das Wort "Persistenzschicht".   LOL)

[Christopher]

Hallo lieber King,

es ist suess anzusehen, wie Du dich hier bemuehst, doch bloss irgendetwas zu finden - sei
es ein Namensvetter meinerseits -, wodurch du dich - zumindest subjektiv - ueber mich stellen
kannst.
Warum? Ist es zu schwer fuer dich einzusehen, dass es Dinge gibt, von denen Du noch nie etwas
gehoert hast, google aber ueber satte 1.5 Millionen Eintraege ausspuckt?

Nichtwissen ist doch keine Schande, nicht war, KING lully?

Gruesse
Christopher

[King^Lully]

Du leugnest also dem anderen Christopher identisch zu sein trotz gleicher Wesensmerkmale wie Arroganz, mangende Empathie und begrenztem Dachwissen? - Kaum zu fassen, Dein Stil und der Deines "Namensvetters" sind doch identisch. Sei mal ehrlich, warst Du der andere Christopher?

[Tim Tepaße]

Hallo,

Aber, da gebe ich dir vielleicht recht, in kleineren Projekten
ist es vielleicht ein wenig overkilled ...

Wobei sich das verändern zu scheint, bei MVC Web-Frameworks wie Ruby on Rails, Django, TurboGears, Symfony sind ORMs durchaus auf dem Vormarsch; werden teilweise sogar erwartet. Nun ja, kommt ja auch immer drauf an, wie man klein definiert. ;)

Tim

[Christopher]

Hallo Tim,

ineteressant. Meiner Meinung nach ist das auch genau der Weg,
den die Entwicklung von Frameworks gehen sollte - auch im Web-
Umfeld

Freudige Gruesse aus Berlin
Christopher

btw: und das mit dem "overkilled" habe ich auch nur geschrieben,
um King Lully nicht noch mehr auf die Fuesse zu treten ;)

[D.R.]

Hallo,

Ist OOP in PHP sinnvoll?

Auf jeden Fall. Allerdings solltest du mindestens PHP 5 einsetzen können. In der 4-er Version ist OOP ziemlich schwierig.

Wenn ja, warum?

Du hast jederzeit Zugriff auf alles, was du bereits irgendwo erstellt hast. Es ist also kein Problem, einen kompletten Elementbaum vorzugeben und nachträglich ein paar Attribute irgendwo einzuhängen.

Außerdem entfällt die nervige Escaperei, weil du Textknoten bei der Ausgabe dann einfach durch htmlspecialchars() jagen kannst.

Zu alle dem: Versuche mal einen XML-Fehler zu produzieren, wenn du konsequent Objekt Orientiert programmierst - unmöglich!

warum nicht?

Als Nachteil könnte sich vielleicht ein kleiner Performance-Verlust erweisen (weil du das Objekt ja erst wieder umwandeln musst). In wie weit das relevant ist, habe ich noch nicht getestet.

Ich kann mir PHP ohne OOP jedenfalls kaum noch vorstellen ;-)

mfg. Daniel