Aufgaben mit LiveBindings und Delphi-DB's erledigen

[haentschman]

Moin...

Zitat:

...scheint das eine einfache, kompakte Sache...

Gegenargumente:
* iteriere durch die Datenmenge... sagen wir um etwas zu suchen und zu berechnen. Was macht das Grid? Aushängen / Einhängen...Arbeit Extra.
* nur VCL
* im Vergleich zu generischen Listen schnarch langsam (ggf. Eventorgien)
* ClientDataSet war mal (ist noch?) verbuggt
* mit ClientDataset geht noch... aber füge mal einer Datenmenge die aus der DB geholt wird 2 Felder für die Anzeige hinzu oder ändere die Anzeige. (Beispiel: in der DB steht nur der Index für einen Wert, der Klartext in einem String Array. In der Anzeige willst du aber Klartext. (Feldtypen passen nicht)... Leerfelder dazuholen und extra füllen ist die Devise... = Basteln
* versuche mal in einer numerischen Spalte in Abhängigkeit vom Wert eine unterschiedliche Anzahl von Nachkommastellen darzustellen. Das geht nur über selbst Zeichnen. Da fängt die Bastelei schon wieder an.
* wenn du dann noch im Grid editieren willst, hast du verloren. (Da gabs gerade etwas dazu)
* du bist auf die Optik der DB Controls angewiesen... teilweise verstaubte W95 Optik. Teilweise keine konsistente Darstellung der DB Controls.
* (Query - Edit, Post etc.) besser saubere SQL als nicht zu wissen was wirklich mit welchem Overhead in der Komponente passiert.
* Verwaltung der SQL Statements extern...also nicht in der Komponente verteilt über die Anwendung.
* wenn man mal mit der Bastelei angefangen hat wird der Code u.U. immer schlechter wartbar, weil man an verschiedenen Stellen nachhelfen muß.
* man kann nicht eben mal sagen... "Das Grid mag ich nicht mehr. Ich mach das jetzt mit Edits..." (Austauschbarkeit der GUI Schicht)

Zitat:

Jedoch muss da immer viel händisch regeln

... kannst du das näher erklären? Ich finde das ORM deutlich übersichtlicher da eine strickte Trennung zwischen der DB Schicht und der Logik herscht.

Zitat:

wie einfach man mit dem ClientDataset filtern oder sortieren kann

... imho ist das Sortieren nicht (unbedingt) die Aufgabe der Datenmenge sondern die der Anzeige (Spaltensortierung). Eine vernünftige Vorsortierung aus der DB ist u.U. auch durchaus hilfreich. Die Datenmenge ist beispielsweise nach ID sortiert, die Anzeige nach der Farbe der Unterhosen...

Fazit:
Ich habe gerade ein Projekt wo unbedingt DB Grids gefordert sind. Was ich, um die Darstellung zu gewährleisten, teilweise für Verrenkungen machen muß... Je komplexer die Anforderung umso größer die Bastelei. Für meinen Geschmack ist es ein Rückschritt in Technologie aus den 90ern.

...letztendlich bleibt es meine Meinung. Ein schönes Wochenende.

[Uwe Raabe]

Zitat von haentschman:

Gegenargumente:

Grundsätzlich stimme ich dir in Bezug auf die Flexibilität eines ORM zu, aber deine Argumente ziehen in einigen Punkten nicht so ganz. So scheinst du die Events OnGetText/OnSetText von TField vollkommen außer Acht zu lassen. Damit lassen sich sowohl die Index-Lookups (auch bidirektional), als auch die inhaltsabhängige Formatierung relativ problemlos realisieren. Ich benutze das auch in Fällen, wo Datenbankwerte übersetzt werden müssen oder Platzhalter mit aktuellen Werten zu ersetzen sind. Zusätzliche Anzeigefelder werden in der Regel mit Calculated Fields erschlagen. Ach ja, die Optik hat sich in den letzten Delphi-Versionen auch deutlich verbessert.

Nebenbei finde ich es durchaus bemerkenswert, daß ein ziemlich brauchbares ORM wie TMS Aurelius auch ein TAureliusDataset mitbringt, mit dem man die Objektinstanzen des ORM wieder über datensensitive Controls ansprechen kann.

So ganz beiseite wischen würde ich den Ansatz mit datensensitiven Controls noch nicht. Er hat sicher noch eine Weile seine Daseinsberechtigung. Wie mit all diesen Sachen muss man natürlich lernen damit umzugehen und mit der nötigen Erfahrung lassen sich die verschiedenen Anforderungen auch effizient und relativ schnell lösen. Das gilt natürlich für ein ORM ebenso.

[Rollo62]

Hallo Harry,

kennst du die Serie zu LiveBindings von Stephen Ball ?
Da ist es schön beschrieben, und am Ende wird auch gezeigt wie man das von Hand machen kann.

Hier gab es auch schon ältere Threads dazu.

Ich benutze das LB im Moment einer super-simplen, flachen Datenbank mit Sqlite, aber von Hand gesetzt, per LiveBinding.
Funktioniert, aber so ganz traue ich dem Braten noch nicht.
Zumindest läuft das mit Sqlite unter allen Plattformen.

Zu Haentschman's Vorschlag, das wird in der Serie oben auch beschrieben.
Als Objektliste funktioniert das genauso wie in einer Datenbank, das ist den LiveBindings egal wo die Daten herkommen.
Aber ich sehe auch den Speicherbedarf, ich habe immer noch die Hoffnung das eine Sqlite Datenbank nicht alle Daten erstmal in den Speicher lädt.
Bei der Objektliste wird das aber wohl so sein, es sei denn man kümmert sich aufwändig um Laden und Zerstören der
Objekte im Speicher.

Ein fertiges ORM würde wohl auch gehen, das habe ich nocht nicht gecheckt, ist aber doch mit Kanonen auf spatzen zu schiessen.

Diese einfache Anforderung die du unten beschreibst habe ich i.d.R. auch zu 90%, und dafür soll (muss) LiveBindings doch ausreichen, ohne grosse Verrenkungen.


Rollo

[Harry Stahl]

Hallo Rollo,

nein, kannte ich noch nicht, danke für den Link.

Interessant insofern, dass man das entsprechend auch für FMX machen kann (habe ich gerade mal spaßeshalber getestet) und soweit ich das sehe, funktioniert auch alles (incl. Gruppierung der Daten nach Kategorien und Updates der geänderten Daten in alle Richtungen).

DBEdits wurden natürlich durch normale TEdits ersetzt.

In der Anlage ein Screenshot.