ORM Frameworks - macht es sinn ?

Hallo  zusammen,

nachdem ich nun entschieden habe, ein eigenes kleines MVC Framework zu entwickeln (einfach aus den Gründen des DRY Prinzips - weil für einen PHP Entwickler einmal der Tag kommt wo man einfach kein bock hat immer wieder ähnliche Aufgaben zu erledigen was besonders CRUD Anwendungen betrifft), bin ich nun am Punkt angekommen an der es nun an die Datenbank Klassen geht.
Dabei ist mir die Überlegung gekommen, ob ORM oder nicht.
Mich würde interessieren : setz ihr ORM Frameworks ein ?
Ich find die Idee an sich ganz gut bei ORM und auch der Programmierstil von ORM ist in einem MVC basierenden Framework sehr schön übersichtlich, allerdings ist es auch recht komplex ein ORM Framework verstehen zu lernen.
Zudem versteh ich noch nicht genau was das Mapping von tabellen auf Klassen für einen genauen Sinn macht.
Zuletzt schreibt halt das Model ja die Daten über die Abstract Klassen in die Datenbank.
Ich mein ein vorteil ist klar : man könnte Problemlos das Datenbank System wechseln und müste sich nicht um die Querys kümmern - allerdings wie häufig kommt sowas wirklich vor ? In der Regel selten bis gar nicht.

Da gab es definitiv einmal etwas drüber, hier im Forum. Ähnliche Fragestellung.

Auch Wikipedia bietet Basiswissen, weiteres findet sich aber über den netten Onkel mit G leicht. ;)

Prinzipiell: ORM ist die Brücke zwischen der Objekte-Welt und der, naja, relationalen (Tupel-) Wertewelt. Rein objektorientierte Datenbanken hatten es schon immer schwer, die Brücke macht das ganze jedoch auch unnötig.

mir ging es mehr um meinungen und erfahrungen von anderen entwicklern.
Ich find die syntax zwar ganz schön, aber bei joins auf anderen tabellen finde ich wird es unnötig kompliziert - und die benötige ich schon etwas häufiger .
Ich denk ich werd mir dann einfach doch ne klasse basteln die nur die datenbank abfragen vereinfacht , das sollte mir dann wohl reichen fürs erste :).

huhu,

ich persönlich finde ein ORM für webanwendungen überflüssig. Eine schlanke Datenzugriffsschicht ist ok, aber ein ORM macht mehr Arbeit als er am Ende erspart, imho :)

Erstmal finde ich, dass es keinen Grund gibt, warum dieser Thread im internen Bereich sein muss...ab in die Lobby mit solchen Sachen.

Objektralationale Mapper sind Fluch und Segen zugleich.

Sie ersparen dir eine RIESIGEN BERG an Arbeit, verdecken aber auch den Datenbankzugriff und damit auch die Frage "Was passiert da eigentlich"?

Ich habe die Erfahrung gemacht, dass OR-Mapper die Arbeit sehr erleichtern, aber bei unbedachter Benutzung grosse Performanceprobleme mit sich bringen können. Begriffe dazu sind "n+1"-Queries bei Lazy Loading.

Arbeitet man auf einem komplexeren Datenmodell, dass eng verknüpft ist, so ist das Risiko umso grösser, da einige Entwickler schlichtweg vergessen, dass die Objekthirarchien, auf denen sie arbeiten, aus der Datenbank gefüllt werden. Das gleiche Problem besteht bei Updates. Hier fällt es irgendwann auch ins Gewicht, dass für ein Update aus Faulheit erst das Objekt geladen wird um dann über die Setter Werte zu verändern...was schonmal zwei Queries verursacht, anstelle von einem.

Ich habe in http://overwatch.de den OR-Mapper Hibernate http://hibernate.org benutzt und bin sehr froh darüber. Allerdings habe ich zwischenzeitlich auch das "Dadrunter" vergessen und entsprechend sind meine DAtebankzugriffe entartet, was jetzt zum Teil wieder behoben ist.

@NeoWhoRU  "...ein eigenes kleines MVC Framework zu entwickeln (einfach aus den Gründen des DRY Prinzips)..."

Pruuuuust...ja Dont repeat YOURSELF...aber wenn das Rad (MVC-Framework) zum 10000. Mal neu erfunden wird ist das ok? Die Logik von kann ich einfach nicht verstehen...

So long...

Maxx

Das kann man natürlich so unterstreichen. Der Einsatz eines mächtigen Frameworks wie des eines ORM setzt mindestens grundlegende Kenntnisse voraus. Allerdings wäre es natürlich ein Trugschluss, dass man ohne ein ORM die Kenntnisse nicht braucht. Die Formulierung "mit weniger Kenntnissen kann man mit ORM weiter kommen" kann daher zutreffen, spätestens bei komplexeren Mappings (etwa HashMaps, ManyToMany mit Attributen, Lazy vs. Eager) ist jedoch Gefahr im Verzug, sich entweder die Daten oder die guten Performance zunichte zu machen.

Persönlich setze ich beruflich für eine Webanwendung (kein Spiel) Spring + Hibernate ein, integriertem und aspektorientiertes (über Annotationen) Transaktionsmanagement eingeschlossen. Die Zeilen stupiden Boilercodes, die man sich dadurch spart, sind fast nicht mehr zu zählen. Die gesparte Zeit kann man für wirklich wichtigen Dinge nutzen.

Original von NeoWhoRU

nachdem ich nun entschieden habe, ein eigenes kleines MVC Framework zu entwickeln (einfach aus den Gründen des DRY Prinzips - weil für einen PHP Entwickler einmal der Tag kommt wo man einfach kein bock hat immer wieder ähnliche Aufgaben zu erledigen was besonders CRUD Anwendungen betrifft), bin ich nun am Punkt angekommen an der es nun an die Datenbank Klassen geht.

Ich habe das mal vor ein paar Jahre in Perl gemacht - ein eigenes, kleines Web-CMS. Vom Lerneffekt her eine gute Sache, von der Sicherheit her auch - aber vom Arbeitsaufwand ... naja, mittlerweile benutze ich eines von der Stange. Und MVC-Frameworks: das ist ebenfalls viel Aufwand, für etwas, was es schon in guter Qualität gibt (es sei denn, du hast eine Idee, wie man da etwas substantiell verbessern kann - lass hören )

Dabei ist mir die Überlegung gekommen, ob ORM oder nicht.
Mich würde interessieren : setz ihr ORM Frameworks ein ?
Ich find die Idee an sich ganz gut bei ORM und auch der Programmierstil von ORM ist in einem MVC basierenden Framework sehr schön übersichtlich, allerdings ist es auch recht komplex ein ORM Framework verstehen zu lernen.

Wenn du objektorientiert programmierst und eine relationale Datenbank verwendest, kommst du um ORM nicht herum. Alles andere ist nicht "the right tool for the job". Ausnahmen bestätigen die Regeln, es _kann_ natürlich einen Grund geben, rohes SQL zu schreiben. Aber im Normalfall... spart es eine Menge Arbeit. Ungefähr die Menge an Arbeit, die man hat, wenn man so ein ORM-System debuggen muß (will sagen: irgendwann macht ein ORM natürlich Probleme, und dann kommt man um eine tiefergehende Beschäftigung damit nicht herum. Trotzdem: alles selbst schreiben hört sich vielleicht toll an, ist es aber nicht).

Zudem versteh ich noch nicht genau was das Mapping von tabellen auf Klassen für einen genauen Sinn macht.
Zuletzt schreibt halt das Model ja die Daten über die Abstract Klassen in die Datenbank.
Ich mein ein vorteil ist klar : man könnte Problemlos das Datenbank System wechseln und müste sich nicht um die Querys kümmern - allerdings wie häufig kommt sowas wirklich vor ? In der Regel selten bis gar nicht.

Naja, bei einem Kunden muß das Cinnamon-CMS (wenn ich das hier mal erwähnen darf ;) ) mit MS-SQL-2000 unter Windows 2000 arbeiten. Aber entwickeln tue ich es unter Postgres / Linux. Ohne Hibernate-ORM wäre das nicht sinnvoll zu machen. Für LittleGoblin wollte ich Postgres unter Windows verwenden (weil der Testserver das halt hat), aber nach einigen unerquicklichen Fehlschlägen bei der Installation habe ich die Config geändert und nun läuft es unter MySQL... die Flexibilität eines ORM ist schon mal ein wesentlicher Pluspunkt gegenüber handgestricktem SQL.

Bei LittleGoblin hat das ORM genau den Sinn, daß ich mich nicht mehr damit beschäftigen muß, als nötig. (Wobei es natürlich gut ist, wenn man weiß, was man tut bzw. was da im Hintergrund passiert - keine Frage.)

http://dewarim.com/browsergame/images/classDiagram-0.1.34.png/image

Zeigt ein altes Klassendiagramm. Browserspiele werden schnell komplex... und im Fall von Grails werden die Beziehungen zwischen den Objekten fast wie von selbst (mit Hibernate) erstellt, ohne daß ich auf SQL-Ebene von Hand umfangreiche Joins formulieren muß.

Original von MrMaxx
Erstmal finde ich, dass es keinen Grund gibt, warum dieser Thread im internen Bereich sein muss...ab in die Lobby mit solchen Sachen.

Da es eine Entwicklerbezogene Frage ist, hatte ich es in den Entwickler Bereich gepackt - ganz einfach weil hier die Entwickler gefragt wurden ;)
Mir ist das allerdings egal obs public ist oder nicht .

Original von MrMaxx

@NeoWhoRU  "...ein eigenes kleines MVC Framework zu entwickeln (einfach aus den Gründen des DRY Prinzips)..."

Pruuuuust...ja Dont repeat YOURSELF...aber wenn das Rad (MVC-Framework) zum 10000. Mal neu erfunden wird ist das ok? Die Logik von kann ich einfach nicht verstehen...

So long...

Maxx

Verlangt auch keiner von dir daß du es verstehst :P
Was heißt rad neu erfinden - ich hab jetzt ne woche gebraucht um das Framework zu programmieren und alle Dinge reinzubringen die ich immer brauche und das System so aufgebaut daß es logisch und sinnig ist und es für mehrere Anwendung nutzbar ist (das war ja der Grund wieso ich es überhaupt entwickelt hatte).
Bevor ich das entwickelt hatte , hab ich mir natürlich schon fertige Lösungen angeschaut (Zend ,Cake u. Adventure Framework) , allerdings galt hier das gleiche wie teils für ORM :
- Die Einarbeitungszeit ist enorm in solche Frameworks - viele Dinge sind natürlich toll , viele Dinge find ich einfach nur sinnlos (wie du es beispielsweise auch sagtest - cake definiert für seine "Modelle" daß diese immer einer Datenbank Tabelle zugehören - halt ORM.

Man kann zwar umständlich ein Join ausführen , aber dann kann ich mir das ganze direkt sparen.
Das war der Grund weswegen ich mir am Ende gesagt habe "das schreib ich selbst " - soll ja auch nicht das mega uber Framework werden - sondern nur einen riesen teil an arbeit abnehmen was ich persöhnlich so benötige.
Durch das Helfersystem (welches dafür gedacht ist componenten zu laden die jedes Projekt auf jeden fall benötigt) und durch das Plugin System(welches nur Komponenten zur Verfügung stellt welche Teile/die Anwendung benötigt) hab ich mir jetzt schon viel Arbeit gespart ;)
Jetzt fehlt mir nur noch eine Helfer Klasse und das ist die DB (wobei ich schon eine reine MySQL Klasse habe - allerdings nur für RAW Querys) - daher kam bei mir die Frage da auf ;).
Allerdings - und das ist ja das schöne am MVC System - kann ich jetzt auch beigehen , raw querys und die mysql klasse nutzen , denn sollte ich mich später anders entscheiden, müssen sowieso nur die modelle angepasst werden und man könnte beide Helfer parallel betreiben.

@dewarim : Klar gibts viele in guter Qualität und nein mein Framework wird auch nicht das supertollewasesnochnichgibt framework - sondern einfach eins daß für meine bedürfnisse reicht und einfacher erweiterbar ist in form von helfern und plugins.

Was ORM betrifft werd ich mal schauen.
Definitiv würde ich dann aber hier ein fertiges nehmen - sollte ich mich dazu entscheiden (denk da an Propel oder Doctrine).

Also in Cake kann man auch "table-less" Modelle erstellen und nutzen. Kann ich jetzt nicht referenzieren, aber bin mir sicher.

Allerdings - und das ist ja das schöne am MVC System - kann ich jetzt auch beigehen , raw querys und die mysql klasse nutzen , denn sollte ich mich später anders entscheiden, müssen sowieso nur die modelle angepasst werden und man könnte beide Helfer parallel betreiben.

Was hat das mit MVC zu tun? Was haben Queries überhaupt außerhalb von M bzw. der Serviceschicht zu suchen? Worauf ich hinauswill: Das sind zwei verschiedene Techniken. Zwei Welten.

Du sprichst die lange Einarbeitungszeit an; das ist richtig. Aber glaubst du, dass neue Entwickler sich bei deinem sofort zu recht finden würden? Oder aber dein Framework kann nicht viel. Dann stehst du allerdings jederzeit vor dem Problem, dass eine Verbesserung erst Implementierung im Framework vorhersieht. Das kann entsprechende Entscheidungen (etwa Aufwand/Kosten) beeinflussen, die nicht sein müssten. Konkretes Beispiel? Cache-Handler wie Memcache, Ehcache oder mein bereits oben angesprochenes Feature von Relationen mit Attributen bzw. Composite-Objects (Subkomponenten, um etwa allgemeine, wiederkehrende Eigenschaften/Spalten zu nutzen).

Im Endeffekt ist es natürlich jedem selbst überlassen. Die Eingangsfrage war: Haben(!) ORMs Sinn? Ja. Sollte man sie selber bauen? Ich rate davon ab, es sei denn, man weiß wirklich was man da tut. Wenn es ein Killerfeature hat, ist das was anderes. ;)

Definitiv würde ich dann aber hier ein fertiges nehmen - sollte ich mich dazu entscheiden (denk da an Propel oder Doctrine).

Von Propel und Doctrine 1.x möchte ich dir aus eigener leidvoller Erfahrung abraten. Beide benötigen Schemafiles und eine ordentliche Prise manueller Konfiguration. Beide Frameworks betreiben außerdem Code Generation für ihre Basisklassen, was ebenfalls eher ein softwaretechnisches Relikt ist.

Frameworks, welche ihr Schema direkt im Model definieren und daraus automatisch Datenbankmigrationen durchführen können, sind sehr viel angenehmer zu verwenden. Daher solltest du dir - wenn du so oder so ein neues Projekt startest - auf jeden Fall man Doctrine 2 anschauen.

Original von knalli

Was hat das mit MVC zu tun? Was haben Queries überhaupt außerhalb von M bzw. der Serviceschicht zu suchen? Worauf ich hinauswill: Das sind zwei verschiedene Techniken. Zwei Welten.

...

Im Endeffekt ist es natürlich jedem selbst überlassen. Die Eingangsfrage war: Haben(!) ORMs Sinn? Ja. Sollte man sie selber bauen? Ich rate davon ab, es sei denn, man weiß wirklich was man da tut. Wenn es ein Killerfeature hat, ist das was anderes. ;)

ORM und MVC sind natürlich 2 unterschiedliche Techniken.
Was ich meinte ist eher : das Model ist ja für die Datenbeschaffung zuständig. Sprich alle Querys bzw. Abfragen würden ja im Model stattfinden (zumindest laut der MVC Struktur - in der Praxis wird dies auch gern mal durch den Controller erledigt, was ich allerdings nicht für sinnvoll halte).
D.h. du könntest ein Model gegen ein anderes austauschen wenn es das gleiche Ergebniss liefert nur auf einem anderen Wege.
Das meinte ich eigentlich ursprünglich damit :)
In der ORM Struktur ist dies etwas anders : da repräsentiert ein Model in der Regel eine Datenbank Tabelle und dessen Struktur.
Ich danke dir aber für die Antwort bezüglich ORM. Ich würds definitiv nicht selber basteln  - sondern eher auf eines der fertigen Frameworks zurückgreifen.

Dein Modell innerhalb von MVC enthält deine Daten. Es ist aber nicht unbedingt für deren Beschaffung zuständig.

Wenn du ein klasssches Schichtenmodell hast mit Datenzugriffsschicht, Geschäftslogigschicht und Präsentationsschicht, wie es in vielen Webprojekten zu finden ist, dann findet du das MVC Pattern in der Präsentationsschicht.

Dein Controller interagiert mit der Geschäftslogikschicht und erhält von dieser das entsprechende Modell. Er wählt eine der Anfrage entsprechende View, die wiederum auf das Modell zugreift, um die (html-)Ansicht anzuzeigen.

Du kannst natürlich auch all deine Geschäftslogik in dein Modell reinpacken, inklusive des Datenzugriffs, aber das spart die Beschreibung dieses Musters eigentlich aus. Meine Beschreibung bezieht sich auch nur darauf, wie ich in der Praxis den Einsatz des MVC-Musters gesehen habe und das sind fast alles WebProjekte. In Clientanwendungen, die denen die View nicht an einen Browser ausgeliefert werden sieht das wiederum ganz anders aus. Da benutzt du dann auch das in dem Zusammenhang oft zitierte Observer-Pattern.

Aber um nochmal zum Thema zurückzukommen....in deiner Datenzugriffsschicht residiert in dieser Architektur dann dein OR-Mapper.

Jetzt hab ich zu viel geschwafelt und keine Zeit mehr...ohm...commit ich mal trotzdem...

Original von NeoWhoRU

Was ich meinte ist eher : das Model ist ja für die Datenbeschaffung zuständig. Sprich alle Querys bzw. Abfragen würden ja im Model stattfinden (zumindest laut der MVC Struktur - in der Praxis wird dies auch gern mal durch den Controller erledigt, was ich allerdings nicht für sinnvoll halte).

Never ever durch den Controller. Das ist nicht "nicht sinnvoll", sondern grob fahrlässig für die Zukunft und einfach nur auf Faulheit zurückzuführen. Harte Worte; aber jeder Entwickler inkl. des Verursachers würde es Wochen/Monate später danken. Weil entweder die Situation hingenommen wird (redundanter Code, prinzipiell nicht verkehrte "dann-mache.-ich-die-neue-funktion-genauso"-Implementierungen) oder ein zeitaufwendiges Refactoring ansteht. Entweder die Datenbeschaffung wird durch das Model oder durch den Service (oder meinetwegen auch klassisch: Schicht der Geschäftslogik) erledigt. (MrMaxx hat es ja ähnlich beantwortet). Das ist dann auch eigentlich kein klassisches Drei- sondern ein Vierschichtenmodell: View <- Controller -> Businesslayer -> Model/Data-Layer (-> Datenbank). Spätestens wenn man anfängt, und auf einmal die gleichen Queries zwei mal aufruft, andere Controller "aufrufen" muss, hat man was verbockt.

Wenn die kleinen und schnellen RoR Beispiele vom Controller aus Model-Befehle losschicken, wird die tatsächliche Arbeit auch von dem Model erledigt. Der Controller sollte nur das machen, wofür er gedacht ist: Aufgaben annehmen, verteilen (dispatchen), entsprechend delegieren und an die View weitergeben. Je nach Frameworkwahl funktionieren Teilbereiche davon auch unabhängig von Controller (sagen wir mal: durch einen "übergeordneten Controller").

D.h. du könntest ein Model gegen ein anderes austauschen wenn es das gleiche Ergebniss liefert nur auf einem anderen Wege.
Das meinte ich eigentlich ursprünglich damit :)
In der ORM Struktur ist dies etwas anders : da repräsentiert ein Model in der Regel eine Datenbank Tabelle und dessen Struktur.

Sobald man ein ORM verwendet, baut man sich eh automatisch wahrscheinlich kleine Utilities, denkt man das zu Ende, hat man den Service- bzw. Geschäftslayer.