Datenbankanwendung GUI

[scrat1979]

Hallo zusammen,

da ich in nächster Zeit ein größeres datenbankbasiertes Projekt starten möchte, wollte ich mal mit einer kleinen Anwendung starten, um mich mit dem best möglichen Design vertraut zu machen. Das ist auch der Grund, warum ich für das beschriebene Projekt eine Firebird-Datenbank verwenden möchte, auch wenn es etwas übertrieben scheint. Außerdem liegen die Daten bereits in einer Firebird-Datenbank...

Das Programm soll eine kleine Verwaltung der Seriennummern meiner erworbenen Software darstellen. Die DB verfügt ganz einfach über 2 Tabellen: TAB_SOFTWARE mit allen Stammdaten sowie eine Tabelle TAB_ATTACHMENTS für etwaige Key-Files. Also ganz einfach gehalten, die Datensätze in TAB_ATTACHMENTS sind über einen Foreignkey mit TAB_SOFTWARE verbunden. So weit so gut...

Nun zur eigentlichen Frage: Wie würdet ihr die Datensätze in die Anwendung einlesen? Es gäbe ja verschiendene Möglichkeiten

1. Am einfachsten wäre es, datenbanksensitive Komponenten zu verwenden und zwei TTable-Komponenten, in welchen ich über eine Master-Detail-Beziehung die Datensätze der Tabelle TAB_ATTACHMENTS filtere. Ich arbeite jedoch nicht so gerne mit diesen Komponenten, da ich das Verhalten der Anwendung lieber selber steuern möchte und mittels TQuery's für Datenbankaktionen arbeite. Außerdem scheint mit der Netzwerktraffic am höchsten zu sein (vor allem, wenn die Anwendung auch über das Internet vertretbar schnell laufen soll...)

2. Momentan mache ich es jedoch so, dass ich zunächst mittels SELECT die ID sowie die Namen der Programmen in ein Grid einlese (nicht datensensitiv!) - quasi als alpahbetische Übersicht. Bei klick auf die Zeile wird über ein weiteres SELECT die Detailinformation des ausgewählten Programmes (Seriennummer, Registriername, Homepage etc.) über die ID eingelesen und über Labels angezeigt. Im gleichen Zug werden in einem weiteren Grid die Attachments - falls vorhanden - angezeigt (auch mittels SELECT ermittelt). Dieses Vorgehen scheint mir am praktikabelsten und mit dem geringsten Traffic zu sein.

3. Habe schon viel in dem Zusammenhang über TClientDataset gelesen, allerdings bislang nicht wirklich verstanden. Sollten diese in der Lösung wichtig sein, dann muss ich mich nochmals damit auseinandersetzen.

Oder ganz allgemein, wie würdet ihr das Design der Anwendung machen bzw. das Einlesen der Datensätze (Übersicht -> Detailinformationen) bewerkstelligen.

Liebe Grüsse,
Michael

[Furtbichler]

Für das bischen was Du machst, reicht der RAD-Ansatz mit datensensitiven Steuerelementen doch aus.

[scrat1979]

Zitat:

Zitat von Furtbichler (Beitrag 1142060)

Für das bischen, was Du machst, reicht der RAD-Ansatz mit datensensitiven Steuerelementen doch aus.

Das stimmt natürlich. Jedoch habe ich deshalb ja ganz oben im Post erwähnt, dass es mir um die BESTE Lösung (auch für umfangreichere Projekte...) und nicht um die schnellste Lösung geht, da ich ja Erfahrung diesbezüglich für ein sehr viel größeres Projekt an diesem kleinen Beispiel sammeln möchte!

[haentschman]

Hallo,

Zitat:

Für das bischen, was Du machst

...hast du schon Recht. Aber so ein kleines Projekt ist auf Grund der Übersichtlichkeit eine gute Spielwiese zum Ausprobieren.

Persönliche Meinung:
Ohne datensensitive Steuerelemente bist du richtig. Meistens kommen später erst diverse Probleme. Wenn du eine Query hast die aus verschiedenen Tabellen Informationen enthällt kommst du mit datensensitiven Steuerelementen nicht mehr hin. Der nächste Schritt ist ein kleines OPF. Das bedeutet du machst aus jedem "Datensatz" ein Objekt. Seid ich diese Technik benutze möchte ich sie nicht mehr missen.

[Furtbichler]

Stimmt. Beschäftige dich mit ORM, z.B. mORMot

Ich verwende datensensitive Steuerelemente eigentlich nur noch, um Daten anzuzeigen.

[haentschman]

Zitat:

Ich verwende datensensitive Steuerelemente eigentlich nur noch, um Daten anzuzeigen.

ok... laß ich als Ausnahme gelten :zwinker:
Wenn du die Daten z.B. eh in einem Objekt hast brauchst du auch kein datensensitives Control mehr. Persönlich hatte ich damit nur Probleme. (Visuelle Geschichten)

[scrat1979]

Zitat:

Zitat von haentschman (Beitrag 1142065)

Zitat:

Ich verwende datensensitive Steuerelemente eigentlich nur noch, um Daten anzuzeigen.

ok... laß ich als Ausnahme gelten :zwinker:
Wenn du die Daten z.B. eh in einem Objekt hast brauchst du auch kein datensensitives Control mehr. Persönlich hatte ich damit nur Probleme. (Visuelle Geschichten)

Okay, das war tatsächlich auch mein erster Gedanke. Ein Objekt TApplicationInfo (o.ä.), welche alle Eigenschaften und Methoden besitzt, welche sich mit dem Auslesen und den Eintragungen in der Datenbank beschäftigen. Das ganze wird dann in einer ObjectList verwaltet. Das ist ja in so einem kleinen Projekt auch problemlos möglich, mir erscheint das allerdings bei größeren Projekten mit vielen verschiedenen Datensätzen respektive Objekten mit erheblichem Programmier- / Schreibaufwand ( Für jedes Objekt Methoden, Properties etc.) verbunden zu sein. Zugegebenermaßen wird die Wartung natürlich deutlich vereinfacht und GUI und Funktion wären optimal getrennt. Hast Du das Vorgehen so gemeint? Dann werde ich wohl meinem ersten Bauchgefühl doch folgen :)

Grüsse,
Michael

[haentschman]

Du hast es genau erfaßt. Sicher ist die Verwaltung über Objekte mehr Schreibaufwand. Hinterher ist es aber besser wartbar, erweiterbar usw. Gerade in größeren Projekten kommen die Vorteile besser zur Geltung.

PS: Dein Bauchgefühl war korrekt... :zwinker:

[Bummi]

Wobei die Frage ist ob man grundsätzlich auf RAD verzichten sollte, mit kommt man recht weit und wie der Name schon sagt ist es um Welten schneller umgesetzt.

[stahli]

@scart1979
Ähnliches hatte ich hier gefragt: http://www.delphipraxis.net/165090-g...ml#post1141764
"Die optimale Lösung" gibt es wahrscheinlich nicht.

@Furtbichler

Zitat:

Zitat von Furtbichler (Beitrag 1142063)

Stimmt. Beschäftige dich mit ORM, z.B. mORMot
Ich verwende datensensitive Steuerelemente eigentlich nur noch, um Daten anzuzeigen.

Hast Du mORMot auch schon mal in größeren Projekten im Multiuserbetrieb eingesetzt?

[scrat1979]

Okay, dann werde ich mich wohl mit der Schreibarbeit abfinden :) Auch das mORMot schaue ich mir mal näher an...

Danke an alle für die prompte Antworten!

[Furtbichler]

Die zusätzliche Schreibarbeit habe ich in einem Codetemplate erschlagen. Der Aufwand hält sich in Grenzen:

Delphi-Quellcode:

Type
  TDataDialog = Class(TForm)
  ...
  protected
    Procedure DataToDialog (aData : TMyData); Virtual; Abstract;
    Procedure DialogToData (aData : TMyData); Virtual; Abstract;
  public
    Class Function Edit (aData : TMyData) : Boolean;
  End


class function TDataDialog.Edit(aData : TMyData);
Begin
  With TDataDialog.Create(Nil) do 
  try
    DataToDialog(aData);
    Result := ShowModal;
    If Result then
      DialogToData(aData);
  finally
    Release;
  End
End;

Ableiten, die beiden Methoden überschreiben (was ja nun kein großes Ding ist) und fertig. Alles ist stringent gleich und damit übersichtlich.

Zusätzlich mache ich mir die Arbeit, pro Datenklasse einen eigenen Dialogframe zu basteln. Auch sehr praktisch.

Bei Tabellen ist es etwas schwieriger, hier möchte ich eigentlich nicht auf TDatasets verzichten, das das Design der Tabelle (Spaltenbreite usw) doch die meiste Zeit in Anspruch nimmt.

Ich verwende DevExpress, und habe hier die Wahl zwischen:
Memory-Datasets.. Meine Objektliste kopiere ich in ein memory dataset und kann dann ganz normal arbeiten. Zur Designzeit habe ich Beispieldaten im Dataset.

Custom-Datasource: Hier wird eine DevExpress-Datentabellenklasse überschrieben, die dann nahtlos mit dem Grid zusammenarbeitet. Man implementiert die Getter und Setter jeder Spalte einfach. Ist einsfixdrei erledigt. Logisch: Das Editieren ist damit sofort implementiert.

Letzteres ist eindeutig zu bevorzugen. Mittlerweile können alle meine Grids ihr Layout zur Laufzeit laden und speichern, sodaß ich das Finetuning zur Laufzeit durchführen kann. Farben sind sowieso systemweit gleich, sodaß ich mich einmal festlege und dann...

Wie schon erwähnt, verwende ich TDatasets nur noch fürs Reporting.

Neulich habe ich aus Faulheit (oder weil ich erfahrungsresistent bin) mal wieder mit TDatset & TDBEdit rumgespielt (5 Tabellen). Fazit dieser Gehirnerweichung: Wenn ich keine kurzen Haare hätte, hätte ich jetzt weniger.

Fazit vons Janze: Investiere in ein Dialogframework, das dir das komfortable Bearbeiten der Daten ermöglicht. Mein Favorit ist DevExpress, aber es gibt auch andere (Berg usw). Verwende ORM, am Besten eins, das die Basisarbeit erledigt.

[mjustin]

Zitat:

Zitat von Furtbichler (Beitrag 1142119)

Delphi-Quellcode:

class function TDataDialog.Edit(aData : TMyData);
Begin
  With TDataDialog.Create(Nil) do 
  try
    DataToDialog(aData);
    Result := ShowModal;
    If Result then
      DialogToData(aData);
  finally
    Release;
  End
End;

Ist Release nicht etwas unsicher? Es ist nicht blockierend, die Kontrolle wird sofort an die aufrufende Prozedur zurückgegeben, so dass der Dialog auch nach dem Aufruf von TDataDialog.Edit(MyData) noch existieren und die Nachrichtenwarteschlange weiterhin abarbeiten kann.