![]() |
Datenbank: Firebird • Version: 2.5 • Zugriff über: Devart IBC
Datenbankanwendung GUI
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 |
AW: Datenbankanwendung GUI
Für das bischen was Du machst, reicht der RAD-Ansatz mit datensensitiven Steuerelementen doch aus.
|
AW: Datenbankanwendung GUI
Zitat:
|
AW: Datenbankanwendung GUI
Hallo,
Zitat:
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. |
AW: Datenbankanwendung GUI
Stimmt. Beschäftige dich mit ORM, z.B.
![]() Ich verwende datensensitive Steuerelemente eigentlich nur noch, um Daten anzuzeigen. |
AW: Datenbankanwendung GUI
Zitat:
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) |
AW: Datenbankanwendung GUI
Zitat:
Grüsse, Michael |
AW: Datenbankanwendung GUI
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: |
AW: Datenbankanwendung GUI
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.
|
AW: Datenbankanwendung GUI
@scart1979
Ähnliches hatte ich hier gefragt: ![]() "Die optimale Lösung" gibt es wahrscheinlich nicht. @Furtbichler Zitat:
|
AW: Datenbankanwendung GUI
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! |
AW: Datenbankanwendung GUI
Die zusätzliche Schreibarbeit habe ich in einem Codetemplate erschlagen. Der Aufwand hält sich in Grenzen:
Delphi-Quellcode:
Ableiten, die beiden Methoden überschreiben (was ja nun kein großes Ding ist) und fertig. Alles ist stringent gleich und damit übersichtlich.
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; 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. |
AW: Datenbankanwendung GUI
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:25 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz