Hallo!

Mich würde mal gerne interessieren, wann man besser mit datensensitiven Komponenten arbeitet und wann nicht.
Ich stelle mir z.B. vor, dass meine Datenbankklassen die Datensätze in meine Geschäftsobjekte laden. Ich habe Objekte wie Rechnung, Kunde usw.

Wenn ich nach dem MVC oder MPV Pattern gehe, gibt es darüberhinaus Klassen, die diese Daten in meinem Fenster anzeigen.
Diese ganze Aufteilung fällt ja hinsichtlich der DB eigentlich weg, wenn ich mit einem TDBEdit, TDBMemo usw arbeite, richtig?

Habe ich denn mit datensensitiven Komponenten weniger Flexibilität? Wo liegen die Nachteile (außer im Aufwand), wenn ich alles selbst in die Felder einlese und auf diese DB-Komponenten verzichte?

Danke für eure Hilfe!
Gruß, Andy

sunnyandy hat folgendes geschrieben:

Hallo! Mich würde mal gerne interessieren, wann man besser mit datensensitiven Komponenten arbeitet und wann nicht. Ich stelle mir z.B. vor, dass meine Datenbankklassen die Datensätze in meine Geschäftsobjekte laden. Ich habe Objekte wie Rechnung, Kunde usw.

Das klassische Datenbankmodell von Delphi ist etwas verkorkst.
Das Hauptproblem ist, das es beim Editieren mit datensensitiven Komponenten für die gesamte Zeit, in der die Form aktiv ist, eine Verbindung zur Datenbank besteht. Man hat weder die Transactionssteuerung noch ein evendulles Locking so richtig im Griff.

Eine Alternative wäre die Verwendung eines Clientdatasets.
Hier kann eine Datenmenge offline bereitgestellt werden.
Man hat dann die Kontrolle über Transactionen wieder in der Hand und kann vor dem Rückschreiben auf Konflikte prüfen.

Verwendbar ist das Clientdataset aus Delphi. Das benötigt aber immer die Midas-dll.
Ich selbst verwende für solche Aufgaben das Virtualmemorytable von Corelab.
Dieser Weg ist übrigens in Net standard. (Stichwort offene Datenmengen)


Gruß
Carla

Hallo Carla, danke für deine Antwort!

Ich verstehe noch nicht ganz, warum es ein Problem ist, wenn die ganze Zeit die Verbindung zur Datenbank besteht. Wenn ich also in einem DBEdit etwas ändere, ist die Änderung ohne mögliches Rollback in der Datenbank, habe ich das richtig verstanden?

Warum benutzt du nicht das Clientdataset aus Delphi sondern das von Corelab?

sunnyandy hat folgendes geschrieben:

Hallo Carla, danke für deine Antwort! Ich verstehe noch nicht ganz, warum es ein Problem ist, wenn die ganze Zeit die Verbindung zur Datenbank besteht. Wenn ich also in einem DBEdit etwas ändere, ist die Änderung ohne mögliches Rollback in der Datenbank, habe ich das richtig verstanden? Warum benutzt du nicht das Clientdataset aus Delphi sondern das von Corelab?

Clientdataset ist Geschmackssache. Mir liegt noch die Midas - dll aus früheren Zeiten im Magen.
Und das Virtual Memory Table ist richtig schnell und bietet ein paar Zusatzfeatures. Ich nehme es z.B. auch zur Drucksteuerung im Zusammenhang mit Fastreport.

Bei der Verbindung zur Datenbank muss man zwischen fileorientierten und SQL Datenbanken unterscheiden.

Prinzipiell öffne ich die Form , ändere einen Buchstaben und gehe dann erst mal Mittagessen.
Jede Änderung wird sofort zurückgeschrieben und der Datensatz bleibt gelockt.
Ein Commit oder Rollback zum Bearbeitungsende schließt erst die Eingabe ab.
In einer Singleanwendung ist das Verfahren egal und beide bringen keinen Vorteil oder Nachteil. Erst bei einer serverbasierten Anwendung wird die offene Datenmenge interessant.
(Stelle Dir vor die Daten kommen über Internet oder Intranet, denn wird der Vorteil offensichtlich).


Gruß
Carla