ORM ist ein nettes Modell.
Aber zu Zeiten von Rapid Prototyping finde das fast schon zu unhandlich.
Für jede Änderung muss man viel Code in vielen Dateien umschreiben.

Hat man hingegen eine Kommunikationsschicht zwischen Controller und Model, kann man alle Änderungen zentral übernehmen (eventuell auch in vielen Funktionen)
Andererseits ist Rapid Prototyping ja eigentlich das Konzept von Rails überhaupt. Und dort wird auch alles gemappt.
Aber dafür haben die Jungs Scaffolding implementiert. Konvention über Konfiguration..

Trotz Caching sind ziemlich spezielle Queries über SQL erstens schneller realisiert und zweitens meist auch schneller auszugeführt.
Was bietet Propel in Hinsicht auf Skalierung?

Ich habe mich bisher in keine ORM Frameworks eingearbeitet und auch keine feste Meinung.
Für Spezialanwendungen SQL - für allgemeine Sachen ORM

Ob sich die Verwendung eines ORM lohnt, hängt sehr stark von den Anforderungen ab, die das spätere Produkt erfüllen sollte/muss. Möchte man maximale Kompatibilität erreichen, kommt man schlecht daran vorbei. Es ist ja kein Geheimnis, dass sich jede SQL-Software in ihrem Dialekt unterscheidet. Außerdem bietet ORMapping zugleich das Model in der MVC-Architektur an.
Doch das Ganze hat den Nachteil, dass durch die hohe Abstraktion auch extreme Komplexität entsteht. Je komplexer eine Anwendungen wird, desto schlechter ist die Performance (pauschal). Man muss also entscheiden, ob der, manchmal sogar enorme, Leistungsverlust tragbar ist.

Eine nette Alternative zu Propel ist Doctrine: http://www.phpdoctrine.org

@d0nut: Für Propel gibt es mehrere Plug-Ins in Sachen Skalierbarkeit. Die Performance war aber trotzdem in Version 1.2 grottig. Man munkelt, dass Version 1.3 performanter sein soll, was ich aber noch nicht getestet habe.

Also in Bezug auf Sicherheit und Abstraktion finde ich das PDO ausreichend.
Nicht perfekt (besonders wegen den Eigenheiten bei lastInsertID) aber ausreichend.

Was meinst du mit Queries vorspeichern? Hört sich nach klassischem Caching an
Das würde ich auch klassisch lassen, indem der Programmierer entscheidet, was gecached wird und was nicht.
Intelligente System sind mit Overhead verbunden und daneben gibts ja auch schon den MySQL Query Cache.

Ich würde für das Framework nur ein Interface bereitstellen, damit man "normale" Abfragen genauso bedienen kann, wie gecachte. SPL ist dazu das richtige Stichwort.
Hier gibts auch ein Beispiel über die Verwendung von SPL und PHP. Außerdem ist das PDO dadurch gekapselt und du kannst es notfalls immer noch durch etwas anderes ersetzen.

Ich finde, dass ORMapping allgm. einen enormen Overhead mit sich zieht. PDO ist, wie schon von d0nut gesagt, meistens ausreichend. Eine andere Möglichkeit zur Abstraktion, wäre eine Art SQL Query Builder, mit dem man die unterstützten Systeme in ihrem Dialekt abstrahieren könnte (basierend auf PDO).

Ein ORM macht meiner Meinung erst dann Sinn, wenn das Klientel über ausreichende Ressourcen verfügt (Cluster o.ä.), sonst wird man auf lange Sicht nicht besonders glücklich damit.

Hallo,

Ich arbeite schon sehr lange mit dem ZendFramework, welches ja auch zig Schnittstellen bietet. Aber im Endeffekt ist es nicht weiter als ein Wrapper. Ich würde da ein Kriterium hinzufügen, nämlich was ist Zweckdienlich?

Wenn was schnell gehen soll, bekomme ich nen Hals wenn ich dauernd Queries schreiben muss. Da finde ich kleine Synonyme ganz hilfreich, vor allem wenn es noch mit der View-Schicht gut gekoppelt ist. Auf der anderen Seite habe ich Queries die etwas komplexer sind, die ich gerne selber schreibe. Ich persönlich fonde Propel als eine Behinderung, was aber Geschmackssache ist. Einen Wrapper für PDO reicht da vollkommen aus, wenn er gut mit dem View gekoppelt werden kann. Somit verbiegst du nichts, jedoch bietest du eine Erleichterung. Es bringt dir nichts, wenn du eine "mega" Schnittstelle baust, die nicht zweckdienlich ist.

so long
jd