Aufgaben mit LiveBindings und Delphi-DB's erledigen

[Sir Rufo]

Ähm, du kannst dir die Specifications definieren und zusammenbauen wie du möchtest und das immer wieder wie du möchtest

[Harry Stahl]

Ok, das Event (OnFilterRecord) behalte ich mal in Reserve. Momentan kann ich es wie gewünscht per "Like" lösen, wobei man das in Zusammenhang mit "%" nutzen muss.

Der folgende Filter liefert mir wie gewünscht eine Suche über alle Felder, für den Begriff "grid" alle Einträge zurück, der ihn als Teil enthält (zusätzlich wird noch ein StandardFilter berücksichtigt [FrameWorkFilter], wenn der nicht Leer ist):

Delphi-Quellcode:

procedure TF_ConvertList.bnFindChange(Sender: TObject);
var
  find, AllFieldsFilter: String;
  L: Integer;
begin
  cds1.Filtered := False;

  if bnfind.Text <> '' then begin
    find := QuotedStr ('%'+ bnFind.Text+'%'); //<-- "%" mit Like, "*" für PartialRight-Suche
   
    for L := 0 to cds1.FieldCount-1 do begin
      if L = cds1.FieldCount-1 then begin
        AllFieldsFilter := AllFieldsFilter + cds1.FieldList[L].FieldName + ' like ' + find;
      end else begin
        AllFieldsFilter := AllFieldsFilter + cds1.FieldList[L].FieldName + ' like ' + find + ' OR ';
      end;
    end;

    if FrameWorkFilter <> '' then begin
      cds1.Filter := FrameWorkFilter + ' and (' + AllFieldsFilter + ')';
    end else begin
      cds1.Filter := AllFieldsFilter;
    end;
  end else begin
    cds1.Filter := FrameWorkFilter;
  end;

  cds1.Filtered := (bnFind.Text <> '') or (FrameWorkFilter <> '');
end;

vgl. Resultat der Suche im anliegenden Screenshot. Einen Platzhalter für Feldnamen, der für alle Felder steht, scheint es ja nicht zu geben (Hinweis, ich verwende hier nur das ClientDataset mit dem Datasource, ohne eine Datenbank dahinter).

Insgesamt scheint sich ja da eine erfreuliche Bandbreite an Möglichkeiten aufzutun.

[haentschman]

Hallo Harry...:P
Warum willst du dich in der Datenstruktur an das DataSet, DataSource, DB sensitive Controls Gedöns pressen lassen? Imho holst du dir mehr Flöhe in den Pelz als notwendig. :roll:
Persönlich habe ich mich davon komplett verabschiedet...und ein Klotz am Bein ist weg. :thumb:
Mein Vorgehen:
1. Für die Daten des Programmes existieren einfache Datenobjekte (TPerson z.B.)
2. Diese werden in generischen Listen gehalten.
3. Das Füllen der Listen übernimmt eine Datenschicht welche als Interface implementiert ist. Beispiel: Data.FillList(PersonList: TPersonList)
4. Wenn die Listen gefüllt sind, werden die Daten in einem beliebigen Control dargestellt. Das Objekt hängt an dem jeweiligem Eintrag dran.

Vorteile:
1. Der Programmlogik ist es völlig wurscht wo die Daten herkommen...sie arbeitet mit den Objekten.
2. Die Datenschicht ist austauschbar... (Herkunft der Daten z.B. aus XML oder verschiedenen DBMS)
3. Die Daten können an verschiedene Controls übergeben werden. Du bist nicht auf die VCL beschränkt. Imho auch über LiveBindings.

Je nach Größe und Aufwand kann man sich das ORM (Datenschicht) selbst zusammenstellen (meine bevorzugte Variante) oder es mit einem verfügbarem Framework erledigen lassen.

Zu Filter + Sortierung:
* Sortieren der generischen Listen über Comparer
* Filtern über Neuaufbau der Anzeige über die Kriterien.
* Ableitung der Liste die ähnlich dem Comparer einen Filter erhält / übergeben bekommt. Über einen Getter gibst du die "gefilterte" Liste zurück.

...sieh es als Denkanstoß. :thumb:

...ein schönes Wochenende.

[Lemmy]

ergänzend zu haentschman: Da Du dich mit Datenbanken erst anfängst zu befassen (lt. deinem anderen Thread): Ich würde vermeiden die Datenmenge in einem Dataset nach eigener Willkür zu sortieren - das macht einfach keinen Sinn (wegen mir: Keine Regel ohne Ausnahme) nur damit in der Anzeige eine bestimmte Reihenfolge einzuhalten ist. Dazu gibt es zum einen Datenbankmechanismen (Index, Filter) oder die "bessere" Alternative über eine Datenbankzugriffsschicht bei der die Oberfläche unabhängig von irgend welchen Datenbankmöglichkeiten bestimmen kann wie die Datensätze angezeigt werden

Keine Frage: Die Lernkurve ist steiler, aber der Schritt Zeit in ein ORM zu investieren ist gut angelegt..

Grüße

[Harry Stahl]

Zitat:

Zitat von haentschman (Beitrag 1337607)

Hallo Harry...:P
Warum willst du dich in der Datenstruktur an das DataSet, DataSource, DB sensitive Controls Gedöns pressen lassen? Imho holst du dir mehr Flöhe in den Pelz als notwendig. :roll:
Persönlich habe ich mich davon komplett verabschiedet...und ein Klotz am Bein ist weg. :thumb:
Mein Vorgehen:
1. Für die Daten des Programmes existieren einfache Datenobjekte (TPerson z.B.)
2. Diese werden in generischen Listen gehalten.
3. Das Füllen der Listen übernimmt eine Datenschicht welche als Interface implementiert ist. Beispiel: Data.FillList(PersonList: TPersonList)
4. Wenn die Listen gefüllt sind, werden die Daten in einem beliebigen Control dargestellt. Das Objekt hängt an dem jeweiligem Eintrag dran.

Mal abgesehen davon, dass ich da einfach auch eine Wissenslücke schließen will, scheint es mir so, dass einige der vorgefertigten Datenbank-Komponenten recht hilfreich sein könnten.

Bislang habe ich das überall so gemacht, wie Du es hier beschrieben hast. Jedoch muss da immer viel händisch regeln und es hat mich einfach beeindruckt, wie einfach man mit dem ClientDataset filtern oder sortieren kann. Für kleine Datenmengen scheint das eine einfache, kompakte Sache zu sein.

[haentschman]

Moin... :P

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. :roll:
* 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ß... :roll: Je komplexer die Anforderung umso größer die Bastelei. Für meinen Geschmack ist es ein Rückschritt in Technologie aus den 90ern. :roll:

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

[Uwe Raabe]

Zitat:

Zitat von haentschman (Beitrag 1337684)

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.