Datenbank Frameworks... Welche Vorteile bieten diese?

[juergen]

Hallo,

hier in der DP gibt es ja einige Hinweise zu z.B. TMS Aurelius-, Spring4D oder neu auch DevExpress- Frameworks.
Bis jetzt wende ich bei Verwendung von Datenbanken Querys, Datasets und auch gern Clientdatasets an und habe da eigentlich nichts vermisst.

Ich wäre da interessiert mich weiter zu bilden. Bevor ich das tue wollte ich hier nachfragen.

Welche Vorteile bieten diese Frameworks überhaupt?

Vielen Dank für hilfreiche, einfache Erläuterungen!

[Luckie]

Frameworks vereinfachen die zugrundeliegenden API Aufrufe, fügen zusätzliche Funktionalität hinzu, die, wenn man sie benötigt, nicht selbst implementieren muss. Vergleiche mal die VCL und die Windows API. Die VCL vereinfacht die Verwendung der Windows API wesentlich.

Nachteile sind unteranderem ein gewisser Overhead, den man für diese Bequemlichkeit in Kauf nehmen muss. Auf das Beheben von Bugs und Sicherheitslücken hat man schlechteren Einfluss, da es nicht der eigene Code ist, bzw. man den Code gar nicht besitzt.

Du musst also letztendlich für dich selbst entscheiden, ob der Einsatz von Frameworks für dich sinnvoll ist oder nicht. Willst du nur die Konfiguration eines Programms in einer Datenbank speichern, kommst du wohl ohne ein Framework aus. Willst du ein Lagerwirtschaftssystem entwickeln, nimmt dir das Framework viel Arbeit hat.

[TurboMagic]

Auch FireDAC ist ein Datenbank Framework!
Es vereinheitlicht, soweit möglich, viele Zugriffe auf unterschiedliche Datenbanken und vereinfacht einige Dinge im Umgang mit diesen.

[TigerLilly]

Ja, da kann ich wohl etwas beitragen:
Ich habe den Umgang mit Datenbanken beginnend bei dBase/Clipper, Paradox gelernt und dann weiter zu MSSQL, mySQL und ORACLE. Da waren Delphi-seiteig TQuerys etc angesagt und das habe ich richtig gut verinnerlicht. :- )

Wir haben eine große Legacy-Anwendung, die darauf aufbaut. Die muss aber jetzt modernisiert werden + die Frage war, wie machen? Neben vielen anderen Entscheidung musste auch die der Datenanbindung gelöst werden. Ich hatte zwischenzeitlich ein paar JAVA Projekte + habe dort Hibernate etc schätzen gelernt + mittlerweile gibt es ähnliches ja für Delphi auch. Nach einigem Herumprobieren und recherchieren bin ich letztendlich zu Aurelius von TMS gekommen, wobei es andere Produkte gibt, die auch gut sind.

Die Entscheidung für TMS fiel wegen dieser Punkte:
- das ist ein mit modernen Techniken komplett neu entwickeltes Tool und enthält keine Altlasten oder Tribute an alte Delphi Versionen
- der Support von TMS ist ausgesprochen gut
- ich habe wahrscheinlich über Jahr beobachtet, wie Aurelius gereift ist und Anforderungen aus der Praxis aufgenommen wurden.
- Transaktionen werden unterstützt und Objektversionierung

Was (für mich) für ein ORM/DB Framework spricht:
- Datenbankunabhängigkeit - Dein ORM schiebt zwischen die DB und die Anwendung eine Schicht und dein Code funktioniert gegen mySQL und SQLite ohne Änderung.
- Du klebst beim Programmieren nicht mehr an Tabellen und Attributen, sondern arbeitest mit Klassen und musst dir über die Datenbank keine Gedanken machen
- Es gibt kein Herumgefrickle mit SQL Statements mehr
- Durch die Klassen erhälts du ein viel höheres maß an Testbarkeit und geringerer Abhängigkeiten
- Du entwickelst eine anderen Programmierstil, der nicht mehr an die Datenbank denkt.

Das ORM löst aber nicht alle Probleme:
- zumindest bei Aurelius gibt es (noch) keine Bulk-Operationen
- destruktive DDLs (Felder löschen) sind nicht möglich
- SQL ist Text und als solcher leicht persistierbar, bei einem ORM geht das nicht so leicht

Aber das sind lösbare Probleme. Die Lernkurve ist allerdings auch beachtlich, für mich hat es eine Weile gedauert, das Konzept zu verinnerlichen. An Stelle dass du mit SQL herumtust, baust du halt ewiglange Delphizeilen zusammen. Aber hier hast du die Fehlerprüfung halt überwiegend schon zur Compiletime + nicht erst zur Laufzeit. Ich habe TQuerys echt verinnerlicht + das Konzept wegbekommen dauert. Aber je länger ich mit Aurelius arbeite und Dinge ausprobiere, desto eleganter wird alles.

Ach ja: Das kommt auch immer: Performance ist kein Entscheidungskriterium pro/contra ORM. Der Overhead, den das ORM einführt ist zu vernachlässigen. ORM heißt Datenbank und da liegen Performanceprobleme ganz woanders.

[Lemmy]

Zitat:

Zitat von TigerLilly (Beitrag 1456006)

Was (für mich) für ein ORM/DB Framework spricht:
- Datenbankunabhängigkeit - Dein ORM schiebt zwischen die DB und die Anwendung eine Schicht und dein Code funktioniert gegen mySQL und SQLite ohne Änderung.
- Du klebst beim Programmieren nicht mehr an Tabellen und Attributen, sondern arbeitest mit Klassen und musst dir über die Datenbank keine Gedanken machen
- Es gibt kein Herumgefrickle mit SQL Statements mehr
- Durch die Klassen erhälts du ein viel höheres maß an Testbarkeit und geringerer Abhängigkeiten
- Du entwickelst eine anderen Programmierstil, der nicht mehr an die Datenbank denkt.

Die Datenbankunabhängigkeit ist für mich (aktuell) kein Thema, der Rest kann aber nicht oft genug betont werden:
Wenn Du ein Stück Code schreibst, das ein Problem lösen soll, dann hast Du unterschiedliche Schichten:
* fachliche Logik (was soll überhaupt gemacht werden)
* Sprachlogik (wie funktionieren Schleifen, Bedingungen)
* GUI
* Datenbank (Abfrage, Speicher, Indizes...)

Mit einem ORM ist der dritte Punkt oben weggekapselt. Und wenn Du es dann noch schaffst, deine Logik testbar in Klassen zu verpacken, kannst Du die GUI aus dem aktuellen Problem streichen und das ganze ggf. auch am Ende mit Unittests absichern, d.h. Du musst nicht mehr selbst testen, sondern lässt testen.

Zitat:

Zitat von TigerLilly (Beitrag 1456006)

Das ORM löst aber nicht alle Probleme:
- zumindest bei Aurelius gibt es (noch) keine Bulk-Operationen
- destruktive DDLs (Felder löschen) sind nicht möglich

Gegenfrage: sind das Aufgaben des ORM? Wenn ja, und das ORM bietet keine solchen Möglichkeiten, warum das ORM nicht erweitern? Und wenn nein: Warum dann nicht Klassen schaffen, die genau das machen, aber eben die Komplexität der SQL wiederum vor dem Rest verbergen....? ;-)

Zitat:

Zitat von TigerLilly (Beitrag 1456006)

- SQL ist Text und als solcher leicht persistierbar, bei einem ORM geht das nicht so leicht

Den Punkt verstehe ich nicht wirklich. Warum soll ich SQL persistieren? Und wohin?

[jobo]

Anhand der Antworten wird schon deutlich, dass ein Framework, auch wenn es ein Datenbank Framework genannt wird, ganz unterschiedliche Funktionen realisieren kann.

Hier müsste man sich dann fragen, was man (davon) braucht.

Ohne es jetzt groß aufzuhängen, ich finde ein Blick in eine DB aus einem Persistenzsystem immer mal wieder gerne gruselig. Es liegt auf der Hand, dass die Abstraktion der DB Fähigkeiten erstmal bedeutet, dass der kleinste gemeinsame Nenner genutzt wird.
Was mich zu dem anderen Punkt bringt: Performance dürfte hier von Fall zu Fall schon eine (unangenehme) Rolle spielen. Meist sind aber die Projekte so klein, dass eine DB das alles einfach wegatmet und man ruhig schlampig mit ihr umgehen kann.

[jobo]

Zitat:

Zitat von Lemmy (Beitrag 1456008)

Zitat:

Zitat von TigerLilly (Beitrag 1456006)

- SQL ist Text und als solcher leicht persistierbar, bei einem ORM geht das nicht so leicht

Den Punkt verstehe ich nicht wirklich. Warum soll ich SQL persistieren? Und wohin?

Könnte mir vorstellen, dass es hier um die immanente Logik geht, die in einem SQL Statement steckt / stecken kann und die zwangsläufig (oder zum Glück) sehr kompakte Logik "Darstellungen" liefert.
In einem Objekt orientierten Programm zergliedern sich die Zusammenhänge in Klassenhierarchien (wovon man selten mehr als 2 Ebenen am Stück sieht) und komplexe Relationen gehen im Code unter. (Vielleicht sehe ich das als klassischer SQL Entwickler aber auch einseitig)

[Uwe Raabe]

Zitat:

Zitat von jobo (Beitrag 1456011)

Performance dürfte hier von Fall zu Fall schon eine (unangenehme) Rolle spielen. Meist sind aber die Projekte so klein, dass eine DB das alles einfach wegatmet und man ruhig schlampig mit ihr umgehen kann.

Ich erinnere mich da an ein Projekt, bei dem damals noch die erste Version von Aurelius zum Einsatz kam. Das funktionierte alles ganz wunderbar bis zu dem Zeitpunkt, wo die Datenbank vom lokalen Netz in Azure migriert wurde. Das Erzeugen einer (DB-)Objektliste hatte dann gleich alle Objekte aus der DB geladen, mitsamt aller Child-Objekte (Master-Detail) in der kompletten Hierarchie-Tiefe. Die ganzen Optimierungen, die das DAC in so einem Fall bereitstellt, waren damit hinfällig. Das Programm öffnete sich erst nach mehreren Minuten.

Aber das hat TMS dann ja später erfolgreich in den Griff bekommen. Leider konnte ich darauf damals nicht warten und musste es doch wieder auf die alte Tour machen.

[TigerLilly]

Zitat:

Zitat von Lemmy (Beitrag 1456008)

Zitat:

Zitat von TigerLilly (Beitrag 1456006)

- SQL ist Text und als solcher leicht persistierbar, bei einem ORM geht das nicht so leicht

Den Punkt verstehe ich nicht wirklich. Warum soll ich SQL persistieren? Und wohin?

Naja, man kann zB für eine Suchmaske komplexe WHERE-Bedingungen vorformuliert in einer Tabelle ablegen und der User wählt dann aus, was er braucht. Oder du bereitest irgendwelche SQL-Statements als Abfragen vor. etc etc.

[TigerLilly]

Zitat:

Zitat von Uwe Raabe (Beitrag 1456015)

Ich erinnere mich da an ein Projekt, bei dem damals noch die erste Version von Aurelius zum Einsatz kam. Das funktionierte alles ganz wunderbar bis zu dem Zeitpunkt, wo die Datenbank vom lokalen Netz in Azure migriert wurde. Das Erzeugen einer (DB-)Objektliste hatte dann gleich alle Objekte aus der DB geladen, mitsamt aller Child-Objekte (Master-Detail) in der kompletten Hierarchie-Tiefe. Die ganzen Optimierungen, die das DAC in so einem Fall bereitstellt, waren damit hinfällig. Das Programm öffnete sich erst nach mehreren Minuten.

Aber das hat TMS dann ja später erfolgreich in den Griff bekommen. Leider konnte ich darauf damals nicht warten und musste es doch wieder auf die alte Tour machen.

Ja, das stimmt - Stichwort LazyLoading.

[juergen]

Hallo,

danke an alle für die Hinweise!
Ich habe mir gerade mal ein Video von Aurelius angeschaut https://youtu.be/fIOntD73S8k
Das hat mir schon mal die Augen geöffnet. Sehr interessant.
Ich denke TigerLilly hat es gut beschrieben:

Zitat:

Zitat von TigerLilly (Beitrag 1456006)

Die Lernkurve ist allerdings auch beachtlich, für mich hat es eine Weile gedauert, das Konzept zu verinnerlichen. An Stelle dass du mit SQL herumtust, baust du halt ewiglange Delphizeilen zusammen. Aber hier hast du die Fehlerprüfung halt überwiegend schon zur Compiletime + nicht erst zur Laufzeit. Ich habe TQuerys echt verinnerlicht + das Konzept wegbekommen dauert. Aber je länger ich mit Aurelius arbeite und Dinge ausprobiere, desto eleganter wird alles.

Da ich DevExpress schon habe werde ich mich nun erst einmal näher mit dem ExpressEntityMapping Framework beschäftigen...

Allen einen guten Start in die neue Woche!:dp:

[Frickler]

Was ich mich immer gefragt habe - wenn es kein SQL mehr gibt, wie regelt man eigentlich statistische Asuwertungen und das Reporting, mal von ganz einfachen Listen abgesehen? Objektlisten laden und dann sozusagen von Hand aufsummieren, wie wir das ganz früher bei dBase gemacht haben? Also Auswertung auf dem Client statt auf dem Server?

[mkinzler]

Die eigentlich Speicherung erfolgt ja in einer Datenbank; und auf diese kann man natürlich auch SQL-Abfragen absetzen. Die ORM-Frameworks bieten aber wiederum auch an, Objektlisten wieder auf DataSets zu Mappen.

[jobo]

Zitat:

Zitat von mkinzler (Beitrag 1456139)

Die eigentlich Speicherung erfolgt ja in einer Datenbank; und auf diese kann man natürlich auch SQL-Abfragen absetzen.

Das ist aber dann Reverse Engineering der Logik des Perstitenzframeworks. Stelle ich mir bei größeren Modellen recht unangenehm vor.

Dann lieber so, damit hab ich praktisch keine Erfahrung, stell ich mir aber etwas krückenartig und aufwändig vor gegen SQL:

Zitat:

Zitat von mkinzler (Beitrag 1456139)

Die ORM-Frameworks bieten aber wiederum auch an, Objektlisten wieder auf DataSets zu Mappen.

[mkinzler]

Zitat:

Das ist aber dann Reverse Engineering der Logik des Perstitenzframeworks. Stelle ich mir bei größeren Modellen recht unangenehm vor.

Kommt darauf an, ob man "Database First" oder "Model Frist" verwendet. Hängt aber auch von Komplexität des Models ab, u.U. gibt es dann wenig Unterschiede.

[jobo]

Ok, das ist richtig.

[DasWolf]

Zitat:

Zitat von TigerLilly (Beitrag 1456006)

Was (für mich) für ein ORM/DB Framework spricht:
- Datenbankunabhängigkeit - Dein ORM schiebt zwischen die DB und die Anwendung eine Schicht und dein Code funktioniert gegen mySQL und SQLite ohne Änderung.
- Du klebst beim Programmieren nicht mehr an Tabellen und Attributen, sondern arbeitest mit Klassen und musst dir über die Datenbank keine Gedanken machen
- Es gibt kein Herumgefrickle mit SQL Statements mehr
- Durch die Klassen erhälts du ein viel höheres maß an Testbarkeit und geringerer Abhängigkeiten
- Du entwickelst eine anderen Programmierstil, der nicht mehr an die Datenbank denkt.

Das ORM löst aber nicht alle Probleme:
- zumindest bei Aurelius gibt es (noch) keine Bulk-Operationen
- destruktive DDLs (Felder löschen) sind nicht möglich
- SQL ist Text und als solcher leicht persistierbar, bei einem ORM geht das nicht so leicht

Aber das sind lösbare Probleme. Die Lernkurve ist allerdings auch beachtlich, für mich hat es eine Weile gedauert, das Konzept zu verinnerlichen. An Stelle dass du mit SQL herumtust, baust du halt ewiglange Delphizeilen zusammen. Aber hier hast du die Fehlerprüfung halt überwiegend schon zur Compiletime + nicht erst zur Laufzeit. Ich habe TQuerys echt verinnerlicht + das Konzept wegbekommen dauert. Aber je länger ich mit Aurelius arbeite und Dinge ausprobiere, desto eleganter wird alles.

Ach ja: Das kommt auch immer: Performance ist kein Entscheidungskriterium pro/contra ORM. Der Overhead, den das ORM einführt ist zu vernachlässigen. ORM heißt Datenbank und da liegen Performanceprobleme ganz woanders.

Also die Nachteile der genannten Vorteile sind:
- Entwickelt man eine Datenbankanwendung und beschäftigt sich nicht mit der Datenbank, kann man gleich einpacken und bei Hello World Anwendungen bleiben
- Beschäftigt man sich nicht mit den Tabellen und kümmert sich auch nicht selbst darum, dann gilt genau das Erste
- Beschäftigt man sich nicht mit SQL, dann bleibt es mit dem Wissen über SQL beim "SELECT * FROM Tabelle".
- Ein Programmierstil, der bei einer Datenbankanwendung die Datenbank vergisst, ist für mich absoluter Mist.

Ein ORM bietet eine einfache Möglichkeit, sein Gehirn für Jahre nur auf 25% laufen zu lassen, zu entspannen und sein Level zu halten. Für Berufseinsteiger zum Beispiel ist das genau der Falsche Weg.

[TigerLilly]

Naja, das hat man vor nicht allzu langer Zeit auch übers Programmieren und Assembler gesagt. Würde ich so radikal nicht unterschreiben.

Aber natürlich sind DB-Anwendungen schon was eigenes, ORM hin oder her. Das ORM nimmt dir das Design der DB ja nicht ab, es vereinfacht den Zugriff darauf.

[Rollo62]

Frameworks haben Vor- und Nachteile, wie schon Einiges geschrieben.
Es gibt aber abseits der programmtechnischen Punkte noch andere zu Bedenken:

Vorteile

• Frameworks können neue API und Philosophien reinbringen
• dadurch Vieles vereinfachen (siehe unten beschrieben)

Nachteile

• Frameworks haben hohe Lernkurve (wie schon gesagt)
• Frameworks erhöhen die gesamte Systemkomplexität
• Frameworks erhöhen die Abhängigkeit von 3rd Party
• Frameworks sind selten fehlerfrei und bringen ganz neue Fehlermöglichkeiten
• Ob ein Framework ein spezielles Problem löst kann man erst nach einiger Erfahrung sagen
• Frameworks haben in der Regel eigene Code- und Stil-Philosophien
• Frameworks Code ist nicht immer leicht lesbar
• Frameworks sind nicht immer gut/sauber gepflegt
• Frameworks haben nicht immer einen guten Service
• Frameworks Entwicklung läuft asynchron zur RadStudio Entwicklung,
  d.h. man muss oft länger auf kompatible Versionen bei neuem RadStudio warten.
  Wenn das Framework kritisch ist kann das Probleme bereiten, wenn eine dringende Lösung 2-3 Monate Verspätung hat.

Ich für meinen Teil habe mich über die Jahre konsequent von den üblichen großen Frameworks verabschiedet (Tms, DevExpress, und andere), auch weil diese nicht unerhebliches Geld kosten, und ich im Gegenzug davon max, 10% genutzt hatte.
Kosten/Nutzen war also etwas in Schieflage.
Meine Strategie ist es höchstens gute freie, und konsequent eigene Frameworks zu entwickeln.

Damit bin ich bisher ganz gut gefahren.
Ich meine RadStudio bietet mittlerweile so viel drumherum an, das man auch ohne zusätzliche Verstärkung gut klarkommt.
Ich würde Frameworks nur für bestimmte Spezialfälle einsetzen, wo es sich nicht lohnt etwas Eigenes zu entwickeln (z.B. HtmlEditor, ORM, ...).
Die generellen Frameworks die nur als "Komponentengräber" dienen brauche ich jedenfalls nicht mehr.

[IBExpert]

Sicherlich ist ein Datenbankframework in bestimmten Umgebungen durchaus vorteilhaft für die Produktivität bei einer neuen Anwendung, die auf unterschiedlichen Datenbanksystemen laufen soll.

Das hängt aber ja wie bei fast allen anderen Nachrichten hier schon gesagt davon ab, wie fit man damit ist. Ob der Quellcode irgendwann besser lesbar ist für Kollegen, die sich selber erst mal in dieses Framework einarbeiten müssen, halte ich für ein Gerücht, aber noch schlimmer kann es auf der anderen Seite aussehen. Wir haben diverse Kunden, die in mit Ihren Frameworks mehr oder weniger verbunden sind, aber dann am ende trotzdem als DB immer Firebird ausliefern. Und die von solchen Frameworks erstellten Datenmodelle haben durchaus die Bandbreite von brauchbar bis gruselig. Primärschlüssel sind keineswegs überall Standard, Fremschlüssel schon gar nicht und so manch ein vom Framework generiertes SQL lässt einen daran zweifeln, das der ursprüngliche Framework Entwickler niemals mehr als 1000 Datensätzen in seinen Tabellen hatte. Wirr in Where Bedingungen auftauchende Upper() Funktionen, die keine passenden Expression Index haben, völlig unsinnige "in" Operatoren mit mehr als 1000 Konstanten, bei der dann im nächsten Schritt zu jedem gefunden Records Einzelsqls abgefragt werden, obwohl man die gesamte Datenmenge schon in einem einzige sql haben könnte, tragen dabei nicht gerade zur Performanceverbesserung bei. Und ich liebe die Ausrede "das macht unser Framework eben so, da kann ich nichts dran ändern ..."

Es kommt also wirklich drauf an ob Multiplattform wirklich erforderlich ist. Wenn nicht, dann konzentrier dich lieber auf eine Plattform und versuche deren native Sprache mit allen Vor und Nachteilen zu lernen. Wenn ein Kunde dir zwangsweise einen bestimmten Datenbankserver vorschreibt (passiert immer wieder gerne bei MSSQL Talibans), dann wird der sichelrich auch nicht müde werden, dich für deine vielleicht nicht besonders performanten Abfragen verantwortlich zu machen, ob der ja eigentlich Schuld ist, das du sein Plattform benutzen solltest. Wir haben gerade für einen Kunden eine Schnittstelle zwischen Firebird und MSSQL realisiert, bei der der Endkunde gar nicht sieht, das die Software eigentlich MSSQL nur als zusätzlichen Speicher benutzt und die komplette Datenhaltung und Logik in Firebird läuft, der aber nicht mehr so heisst und auch nicht als solcher erkennbar ist, weil wir den als Applicationserver tarnen.

Wir hatten heute gerade bei einem anderen Kunden einen Fall, bei dem wir relativ komplexe Datensätze nach bestimmten fehlenden Detaildatensätzen durchsuchen musst und wenn der fehlte, diesen dann automatisch anlegen. Das war in der Firebird SP Sprache ein Job, der mit einem execute block innnerhalb von 25 Zeilen Quellcode in weniger als 5 Minuten erledigt war, obwohl ca 50000 Records in Frage kamen und ca. 4500 neu angelegt werden musste. Dafür waren aber eben auch gute Kenntnisse der Fähigkeiten von Firebird erforderlich. Theoretisch hätte das auch jeder qualifizierte Programmierer ohne Front End Programmiererfahrung machen können, auch wenn das dann eben nicht 5 minuten sondern vielleicht 5 stunden dauert. Das Know How kannst du aber generell in vielen Plattformen ähnlich nutzen und wenn du mit richtig großen Datenmenge zu tun hast, sind generalisierende Frameworks sehr oft eine Einbahnstraße, aus der du mit vertretbarem Aufwand nicht mehr rauskommst und dir am ende zusätzlich das Know How der jeweiligen Plattform aneignen musst.

Und ob am Ende ein Client auf Basis eines solchen Frameworks auch nur annährend 100000 bis 200000 insert/update/delete/select statements pro Sekunde schafft, was in einer Firebird SP serverseitig problemlos machbar ist, wage ich auch zu bezweifeln.

Und dabei bezieh ich mich explizit nicht auf TMS, ich weiss das Bruno so was nicht nur rausbringt und nach einem Jahr wieder einstellt, sondern wirklich gut weiterentwickelt und guten Support liefert, aber auch damit bist du in seinem ecosystem spricht delphi gefangen. Dein Know How mit so was in der Art ist recht exotisch und kaum woanders benutzbar. Ich brauch Frameworks daher nicht, aber das hast du vermutlich schon vorher erraten.

[TigerLilly]

Den Profi für die DB wird es immer brauchen. Von allen Applikationen, die gegen eine DB laufen, lassen oder ließen sich sicher 99% unter Verwendung eines Frameworks leichter entwickeln. Nicht umsonst gibt es so viele Frameworks + das für alle Sprachen. Delphi war da eh eine der letzten:

https://en.wikipedia.org/wiki/List_o...pping_software

Es braucht halt das richtige Werkzeug für die jeweilige Aufgabe. Ein ORM ist nicht immer die beste Lösung und umgekehrt ist "kein ORM" auch nicht der Weisheit letzter Schhluss. Ganz sicher aber ist die Kombination sauberes Datenmodell, optimierte und gewartete DB + ORM mehr als attraktiv.

[p80286]

Zitat:

Zitat von IBExpert (Beitrag 1456224)

Und ich liebe die Ausrede "das macht unser Framework eben so, da kann ich nichts dran ändern ..."

man stelle sich vor, ein Abrissunternehmer will mit einem 125g-Hammer eine Mauer einreißen "mein hammer ist halt so!"

Für jeden Job braucht es das richtige Werkzeug und natürlich den, der damit umgehen kann. Oder anders ausgedrückt "Ich nutze XYZ für BlaBla" ist kein Qualitätskriterium.

Gruß
K-H

[juergen]

Hallo,

danke für die Hinweise der Nachteile! Das brauch ich immer wenn ich was neues anfange damit man weiß auf was man sich einlässt.
Ich habe mir inzw. einige Videos vom TMS Aurelius Framework angeschaut. Das ließ sich oft fast 1:1 auf mein DevExpress EMF portieren.:). Erste Testanwendung ist fertig.

Ich bin erst mal beeindruckt was das Framework einem alles abnimmt. Aber anderseits habe ich ein ungutes Gefühl.
Ich habe so gut wie keinen Einfluss mehr auf das SQL Statement was da "hinten" rauskommt. Ich muss dem ganzen also vertrauen.

Für mein herkömmliches, klassisches Handling mit Datenbanken hatte ich mir mal einen SQL Formatter programmiert der im MSSQL Studio erstellte SQL Statements direkt in Delphicode umwandelt und je nach Datentyp mit leeren Vorgabewerten füllt bei Inserts.
Somit habe ich sofort formatierten, lesbaren SQL-Code in Delphi. Aber eben teilweise ewig lang, das ist mit einem Framework wesentlich kürzer.

Ich werde das EMF in einem zukünftigen geeigneten Projekt "einfach mal probieren" und vorläufig erst mal mit Testanwendungen weiter experimentieren.

[p80286]

Zitat:

Zitat von juergen (Beitrag 1456234)

Somit habe ich sofort formatierten, lesbaren SQL-Code in Delphi. Aber eben teilweise ewig lang, das ist mit einem Framework wesentlich kürzer.

Die Länge eines SQL-Statements hat nun überhaupt nichts mit seiner Qualität zu tun. Die Statements, die Du bisher gebastelt hast waren jawohl nicht vollkommen daneben. Dann solltest Du diese mit den von dem Framework erstellten vergleichen und Dir dann ein Urteil bilden.

Gruß
K-H

[DasWolf]

Zitat:

Zitat von p80286 (Beitrag 1456236)

Zitat:

Zitat von juergen (Beitrag 1456234)

Somit habe ich sofort formatierten, lesbaren SQL-Code in Delphi. Aber eben teilweise ewig lang, das ist mit einem Framework wesentlich kürzer.

Die Länge eines SQL-Statements hat nun überhaupt nichts mit seiner Qualität zu tun. Die Statements, die Du bisher gebastelt hast waren jawohl nicht vollkommen daneben. Dann solltest Du diese mit den von dem Framework erstellten vergleichen und Dir dann ein Urteil bilden.

Gruß
K-H

Um die Qualität geht es ja auch nicht. Es geht darum, den ganzen ellenlangen SQL-Text in die entsprechende Unit zu schreiben oder eben sehr verkürzt (aber schlechter lesbar, folglich schlechter wartbar (Stichwort Support)) über das ORM zu schreiben.

[TigerLilly]

Zitat:

Zitat von DasWolf (Beitrag 1456256)

oder eben sehr verkürzt (aber schlechter lesbar, folglich schlechter wartbar (Stichwort Support)) über das ORM zu schreiben.

Nein. Ganz im Gegenteil: Im ORM hast du nur Delphi-Code, den jede/r ProgrammierIn versteht und eben keinen Mix aus Delphi+SQL. (Möge ich nie wieder mit SQL-Statements zu tun haben, die gutgläubige ProgrammiererInnen geschrieben haben.) Es gibt Punkte, die gegen ein ORM sprechen, aber mangelnde Wartbarkeit würde ich dort nicht sehen.

[p80286]

Zitat:

Zitat von TigerLilly (Beitrag 1456257)

Nein. Ganz im Gegenteil: Im ORM hast du nur Delphi-Code, den jede/r ProgrammierIn versteht und eben keinen Mix aus Delphi+SQL. (Möge ich nie wieder mit SQL-Statements zu tun haben, die gutgläubige ProgrammiererInnen geschrieben haben.) Es gibt Punkte, die gegen ein ORM sprechen, aber mangelnde Wartbarkeit würde ich dort nicht sehen.

Dann schau Dir mal Haentschmanns Lösungen hierzu an. Daß es Programmierer(innen) gibt, die ein vollkommen unverdauliches Gebräu aus SQL und Delphi-Code erstellen soll es geben, aber zur Elite ihrer Zunft gehören die ganz sicher nicht.

Gruß
K-H