SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen

[Der schöne Günther]

Ich habe grade nochmal auf ein Datenmodul geschaut dass ich erst mit DBX gemacht hatte und später dann mal komplett gegen FireDAC getauscht hatte. Die DBX-Komponenten sind noch drauf.

Die DBX-Felder sind tatsächlich alle WideMemo, FireDAC war so schlau und gleich überall TimeStamp-Felder, Booleans und AutoIncs erkannt. Nicht übel.

[Sir Rufo]

Da jedes Datenbank-System sein eigenes Süppchen kocht (Datum, Boolean, Texte, etc.) und auch die Verbindungen das immer etwas anders interpretieren, würde ich empfehlen die Anwendungs- bzw. UI-Schicht nicht direkt mit der Datenbank zu verbinden.

"Einfach" die Daten für die Anwendungs-Schicht in Klassen (Model) zusammenfassen, für die UI-Schicht anderen Klassen (ViewModel) und für den Austausch mit der Daten-Schicht ein DTO (DataTransferObjekt) inkl. Assembler (Model <-> DTO).

Ist zugegebenermassen mehr Aufwand als einfach eine Query hinklatschen und mit LiveBinding zu verbinden, dafür hat man aber alles in der Hand und jede Menge Spielraum für die Implementierung ohne sich ständig ins Knie zu schießen.

[arnof]

Zitat von Sir Rufo:

Da jedes Datenbank-System sein eigenes Süppchen kocht (Datum, Boolean, Texte, etc.) und auch die Verbindungen das immer etwas anders interpretieren, würde ich empfehlen die Anwendungs- bzw. UI-Schicht nicht direkt mit der Datenbank zu verbinden.

"Einfach" die Daten für die Anwendungs-Schicht in Klassen (Model) zusammenfassen, für die UI-Schicht anderen Klassen (ViewModel) und für den Austausch mit der Daten-Schicht ein DTO (DataTransferObjekt) inkl. Assembler (Model <-> DTO).

Ist zugegebenermassen mehr Aufwand als einfach eine Query hinklatschen und mit LiveBinding zu verbinden, dafür hat man aber alles in der Hand und jede Menge Spielraum für die Implementierung ohne sich ständig ins Knie zu schießen.

wenn der SQLTreiber nur "Müll" zurückgibt, da nützt die ... nichts!

[Sir Rufo]

Zitat von arnof:

wenn der SQLTreiber nur "Müll" zurückgibt, da nützt die ... nichts!

ganz kaputt kann man nicht heilen aber mit wesentlich geringerem Aufwand den Daten-Layer auf einen anderen Connector umstellen oder auch gleich eine andere DB

Aber so wie du geschrieben hast kommen die Daten doch an (als WideMemo)... mit dem passenden DTO/Assembler kannst du das trotzdem dann verarbeiten

[Mschmidt]

Alternativen Suchen?
Ich verwende seit Jahren UniDac von Devart. Damit geht so ziemlich alles was Mainstream-Datenbanken betrifft. Ist aber leider nicht gratis.
Zumal man, wenn das Db-Design stimmig ist, über ein einfaches Property die Datenbank wechseln kann.
vg. Mathias

[Harry Stahl]

Zitat von Sir Rufo:

Da jedes Datenbank-System sein eigenes Süppchen kocht (Datum, Boolean, Texte, etc.) und auch die Verbindungen das immer etwas anders interpretieren, würde ich empfehlen die Anwendungs- bzw. UI-Schicht nicht direkt mit der Datenbank zu verbinden.

"Einfach" die Daten für die Anwendungs-Schicht in Klassen (Model) zusammenfassen, für die UI-Schicht anderen Klassen (ViewModel) und für den Austausch mit der Daten-Schicht ein DTO (DataTransferObjekt) inkl. Assembler (Model <-> DTO).

Ist zugegebenermassen mehr Aufwand als einfach eine Query hinklatschen und mit LiveBinding zu verbinden, dafür hat man aber alles in der Hand und jede Menge Spielraum für die Implementierung ohne sich ständig ins Knie zu schießen.

Das ist ein Thema, dass mich sehr interessiert (eigentlich müsste man dazu mal einen eigenen Thread aufmachen). Spätestens wenn man Crosscompile-Projekte macht, merkt man, wie wichtig es ist, Oberfläche und Datenschicht / Anwendungslogik zu trennen.

Was Du hier ansprichst, geht ja auch noch einen Schritt weiter, nämlich die Verarbeitung der Datenschicht austauschbar machen (sorry, wenn ich als Jurist und Teilzeit-Entwickler nicht immer die richtige IT-Terminologie treffe).

Ich musste mir mal ein größeres Geschäft durch die Lappen gehen lassen, weil ein Interessent zwar an meinem Adressprogramm sehr interessiert war, er wollte aber als Datenbank ein bestimmtes Format haben und SQL-Abfragen sollten möglich sein. Da musste ich leider passen.

Insofern wäre es Klasse, wenn man das Programm so umschreiben könnte, dass man die Daten von frei wählbaren Datenbank-Engines verwalten lassen könnte. Bei im Übrigen gleicher Oberfläche bzw. leichten Anpassungen an erweiterten Fähigkeiten der jeweiligen Datenbank-Engine.

Nun, da ich ja leider (noch) keine Ahnung von der klassischen Datenbankprogrammierung habe (also die Sachen, die Delphi so anbietet), meine Frage, ob es hierzu entweder Literatur oder Demo-Beispiele gibt, wo einmal demonstriert wird, wie man das von Dir beschriebene Modell implementiert?

[Sir Rufo]

Zusammen mit dem Schlagwort Delphi findet man dazu wenig bis nichts.

Ansonsten gibt es einige Quellen (C#, Java, etc.) die man aber adaptieren kann.

[Harry Stahl]

Ohne den Begriff "Delphi" und nur auf wenige Stichwort Deines Beitrags reduziert, finde ich z.B. das:

http://www.mrknowing.com/2013/11/08/...n-architektur/

Geht glaube ich in die richtige Richtung.

[Sir Rufo]

Zitat von Harry Stahl:

Ohne den Begriff "Delphi" und nur auf wenige Stichwort Deines Beitrags reduziert, finde ich z.B. das:

http://www.mrknowing.com/2013/11/08/...n-architektur/

Geht glaube ich in die richtige Richtung.

Obwohl das auch nur das Thema ankratzt

Da muss man bei jeder Schicht noch einmal in die Tiefe gehen.

Beispiel GUI, da gibt es unterschiedliche Ansätze wie MVC, MVVM, ... wobei ich das MVVM besser finde, weil hier beim ViewModel schon der Schnitt von der GUI erfolgt. Bei MVC kennt der Controller noch die einzelnen Controls und bei Delphi ist somit der Controller auch vom Framework (VCL, FMX) abhängig und kann daher nur bedingt wiederverwendet werden.

Ein ViewModel ist also nur eine Brücke zwischen der UI und dem Rest der Anwendung.

Der Einstieg zum ViewModel mit Delphi wird auch nicht unbedingt leicht gemacht. Viele benötigte und hilfreiche Strukturen sind schon mal gar nicht vorhanden und müssen erst aufgebaut werden.

• MultiCast-Events (nein, die Spring4D-Variante finde ich nicht gelungen) (*)
• ObservableCollection (s.o.)
• ICommand, RelayCommand
• ...

Wenn man das hinter sich hat, dann wird es schon einfacher, aber der Weg ist zunächst steinig.

Auch das fehlende ARC für den Desktop-Bereich steht bei solchen Lösungen teilweise im Weg.

(*) Spring4D lehnt sich ja sehr stark an Visual-C#/.Net an stolpert aber über den unbedingten Willen, das zu 100% Delphi-Event-kompatibel zu machen - was ich persönlich für überflüssig halte - und einige Stellen sind daher nicht mit nativem Delphi-Code zu realisieren wodurch die Portierbarkeit (Android, iOS, OSX) leidet.

Bei .Net sind alle Events gleich aufgebaut mit einem Sender und einem EventArgument. Wenn man das genau so in Delphi umsetzt, dann braucht man das Gefrickel nicht und kommt mit reinem, portierbarem Delphi-Code klar.

Die ObservableCollection in Spring4D feuert bei jeder einzelnen Änderung ein Event (z.B. eine Collection mit 1000 Items feuert bei Clear 1000 Events - eben so wie Delphi das eben macht) wo bei .Net genau ein Event gefeuert wird und beinhaltet u.a. eine Liste mit OldItems, die in diesem Fall eben diese 1000 Items enthalten. Wenn man das UI damit steuert, kann man sich schon ausrechnen, was da besser ist/wäre

[Harry Stahl]

Vielen Dank für Deine ergänzende Information. Da sind wieder eine Reihe von Stichworten dabei, womit man sich der Sache weiter nähern kann.

Diese Art der gehobenen Software-Architektur wäre ja eigentlich auch ein schönes Thema für die Delphi-Tage gewesen...