nicht angemeldet
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!
PO's (Persistenzobjekte)
Besitzen das Mapping der Datenbank zu Objekten - so wie Persistierungsfunktionen (Retrieve,
Select, Update, Insert)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.