Datenbankanwendung UI

[weisswe]

Hallo!

Ich "kämpfe" seit längerem mit meiner UI meiner Datenbankanwendung.

Sie ist multiplatform (Desktop) und arbeitet mit verschiedenen Datenbanken (lokal meist SQLite, online meist MySQL).
In Verwendung habe ich die UNIDAC-DB Komponenten und TMSGrid. Zur Datenbindung verwende ich Livebindings.
Hier liegt auch das Problem - das Zusammenspiel der verschiedenen Komponenten - speziell mit Livebindings - hier sind zahlreiche "Phänomäne" zu sehen.

Darum suche ich auf diesem Weg eure Erfahrung hiermit.
Mein Aufbau:
Ich habe verschiedene Objekte (z.B. Artikel, Artikelgruppen, Kunden, ...).
Diese zeige ich in Listenform an (derzeit TMSGrid)
Viele der Objekte haben auch Filter - Beispiel Artikel -> im Header kann man die Artikelgruppe auswählen -> wonach die Artikel gefiltert werden.

Welche Komponenten / Strategie verwenden ihr für solche Anwendungen?
Bin derzeit etwas ratlos.

Besten Dank,
Werner

[Mavarik]

Da man für eine Anzeige von Daten in Datensensitiven Komponenten immer die Datenbank offen halten muss verwende ich die NIE.

Daher auch keine DB-Grids usw.

Immer lokale Mem-Kopie erzeugen und Datenbank wieder zu... Ab diesem Zeitpunkt ist es wie mit statischen Daten...

Mavarik

[haentschman]

Moin...

[mein Senf]
Von datensensitiven Komponenten lasse ich, genau wegen komischer Effekte, seit Jahren die Finger. Vor Allem im Grid editieren ist der Horror...

Zitat:

Welche Komponenten / Strategie verwenden ihr für solche Anwendungen?

...meine Strategie:

1. programmintern existieren nur generische Listen mit Datenobjekten in der Logikschicht. Die können so schön komplex sein was ein Datensatz nie hergibt...
2. Die Listen werden dann visualisiert...kann man sich aussuchen womit.
3. Das Objekt (Pointer) hängt immer an dem Eintrag der GUI (Liste, TreeNode z.B.) Somit hat man Zugriff auf das Objekt welches den Eintrag repräsentiert.
4. Die Datenbankschicht (Interface) kennt als einzige die Datenbank.
5. Die Logik sagt (vereinfacht) der Datenbankschicht... "fülle mir mal diese generische Liste mit TPerson". TPerson kann aus Master / Detaildaten bestehen. Die Datenbankschicht baut das Objekt aus den Tabellen zusammen.
6. Beim Speichern ebenso... "speichere mir das Objekt(TPerson)". Die Datenbankschicht dröselt das Objekt in die Einzelteile auf und speichert die Master Detaildaten in die DB. (in einer Transaktion)

...fertsch Meister.

[/mein Senf]

[weisswe]

Hallo!

Danke für eure Antworten.
Hab es mir schon gedacht das es da keine fertige Lösung gibt (wie auch).
Zumindest hab ich dann alles "unter Kontrolle", wenn ich es von der DB abkapsle.

Nochmals Danke!!

Schöne Ostern,
Werner

[haentschman]

Moin...

Zitat:

Zumindest hab ich dann alles "unter Kontrolle", wenn ich es von der DB abkapsle.

...der wichtigste Grund überhaupt. Ein weiterer Vorteil ist die Arbeit mit den Daten. Du kannst mal eben über eine generische Liste drüberbügeln und irgendwelche Dinge mit den Objekten anstellen, ohne das die GUI davon was mitbekommt (Berechnung etc.)...und es geht rasend schnell.