SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen

[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...

[Sir Rufo]

Ein interessanter Artikel zu MVVM (nicht an .Net oder WPF stören) ist hier. Nicht zu kompliziert aber auch nicht zu flach (wie die meisten Beispiele)

[MichaelT]

Zu Zeiten von BTRIEVE (Record Server) hat man die binäre Repräsentation eines Record in eine Datenbank abgelegt. Man hat an sich noch mitgegeben wie Character mit Code Pages zu interpretieren waren (Sortierung usw...).

Relationale SQL Datenbanken sind von der API her konzipiert für 4GL. SQL war zu Beginn eine Art Export Facility. Im Prinzip ein klassisches Provisorium. Und wie üblich in der IT hat man drüber gebaut. Es war für Unternehmen eine Befreiung, sie waren nicht mehr vom File Format von Anwendungen und programmierter Zugriffsprogrammen abhängig. Ich kenne noch ITs die haben Listen programmiert in C. So machen IT Leiter nicht heruntergestiegen und auch nicht Produkthersteller. Sichert das Businessmodell des einzelnen Hersteller oder Orgeinheit... Warum glaubst du gibt es soviele Fileformate. Die IT's konnten mit relationalen Datenbanken ihre eigenen Daten auslesen, aufbereiten usw...

Es gibt an sich ein paar Standards. Dann gab es mal ANSI SQL. Diese Standards wurden implementiert und gleichzeitig haben die Datenbankhersteller auch aus durchaus ehrbaren Motiven Programmiersprachen eingebaut in die DBs... damit haben sie den Kunden anders eingefangen. Die sind geliefert in der Praxis. Es gäbe einen Prozeduralen Stand für DBs - der kam zu spät und kann nicht viel. Die Mimer hat den relativ exakt implementiert. - Alles nur DB.

Jetzt hat man 2 Arten von Zugriff. Query - Abfrage und im Prinzip das Ausführen einer Prozedur und Übernahme des Ergebnisses das wiederum eine oder mehrere Tabellenstrukturen sein können. Etwas frei formuliert - explizite und implizite Cursor. Ist das verpackt in einer zumeist in C implementierten library dann spricht man von einem Treiber. ODBC ist ein gelungener Versuch ein normierten Datenbanktreiber zumindest aus Sicht der Anwendung respektive des Programmieres anzubieten. Einige Unterschiede verbleiben, ob des gemeinsamen Nenners. BDE und DB auf Treiber Ebene sind ähnlich gelagert.

DBX wurde von Borland nicht weiterentwickelt. Die Treiber selbst waren an sich gut und das Konzept ansprechend. Die Komponentenseite war nichts ganz sauber. Nach einigen Versuchen im Guten Borland davon zu überzeugen die Komponentenseite zu verbessern hat dann ursprünglich ein Schweizer Unternehmen ihre OffShore (Dmitry Arefiev damals der Treiber hinter dem Ganzen) AnyDAC heute FireDAC geschrieben. Am Anfang wollte man Oracle direkt (NCOCI Ablöse), ODBC (Alternativ OLEDB, das wurde aber verworfen) und DBX unterstützen. Das hat so lala funktioniert, aber die Lösung war eben dann der Umweg über eine eigene SQL Ebene die auf SQL umgesetzt wird, das die Datenbank versteht. Diese normierende Schicht hat auch UNIDAC. Die Komponentenebne (TDataset Compatibility) frisst 40% der Speed.

n-tier. Heißt nichts anderes als die Anzahl von RPC Indirektionen beginnend mit 1. pro Indirektion kommt eine dazu. Der Client Server Zugang (zumeist der Client spricht dem Server über eine eigens Protokoll. Das geht von einfach DEC RPC, IBM CPI-C in gewisser weise, SAP RPC, SAP GUI Protokoll, OCI, SQL PLUS Protokoll usw.. Das sind die 2 Tier Ansätze. Die haben alle eines gemeinsam. Der Client bekommt einen Bytestream und muss den mit bekannter Metainformation (Datensatzaufbau, Characterset usw...) interpretieren sodass mein Funktionsaufruf aus der 3GL Sprache (C, Pascal usw...) etwas verarbeitbares rauskommt.

Im Prinzip wurden dann Elemente eingeführt die RPCs in Empfang nehmen (Proxies, Datasnap, ... usw...). Die Apptier war am Anfang eher eine Pooling Ebene die einfach die DB Sessions sollte entlasten. Klassiker ist (MTS von Microsoft). Der SQL hat in 60 keine 10 User geschafft ... Das war schon ein Schitt in Richtung 3Tier. Klassische 3 Tier ist Java und .net Remoting. Davon losgelöst hat sich CORBA als objektorientierter Zugang stark lastig im Sinne von OO rausgebildet eben noch begrenzt durch die Möglichkeiten des RPC. Das war eine verbesserter RPC zu Beginn. Ein anderer Ansatz sind Appserver - BEA (Objekt Proxies). Java hat damals einfach gewonnen da die Serialisierung weitaus einfach ging als in C/C++ mal ganz zu schweigen davon, dass man mit CORBA Librares RECORDS hat dynamisch zusammengebastelt. Der DB Access war so langsam dass man hergegangen ist und in der Not Java Objekt Repräsentationen hat gepoolt und das hat in der damaligen Zeit die Smalltalk und OO Typen nachdem sie mit OO Database grandios gescheitert waren sehr gut ins Konzept gepasst (ORM und Persistenzcontainer in die Java Appserver). Die Synthese von Dingen die nie funktioniert haben.

Die 3 Tier wurde eingeführt damit man eben noch eine zusätzliche Protokollabstraktion reinbekommt. An sich wäre es so dass die Objekte auf der Apptier genauso lebten und am GUI nur angezeigt werden. Egal wie man technisch Realisiert.

Web ist kein reiner 3 Tier in klassichen Definition. Ein HTTP Request ist eine andere Abstraktionsebene als der traditionelle RPC. In dem Sinne ist HTTP ein alternatives Protokoll zum RPC aber doch ein wenig mehr. Protokolle sind beide.

Jetzt kommt die Gretchenfrage. Erzeugst du dir ein Objektlayer. Ich generiere mir auch einen. Eines darf man nicht vergessen. Eine Select Statement erzeugt zur Laufzeit Typen ... der Typ im Programm ist statischen (Impedance Missmatch). An sich für eine Applikationsperistenz Objekte ja und im schlimmsten Fall Collections aufbauen. Wenn das Ziel der Datenbank in kombinierbare Informationsbasis ist, dann Vorsicht. Objekte sind aus der Sicht zugreifenden Applikation eine Wahrheit die gegen das Informationsmodell beim DML geprüft wird oder alternativ in der TDataset Welt...

Zitat von Harry Stahl:

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?

[Harry Stahl]

Zitat von Sir Rufo:

Ein interessanter Artikel zu MVVM (nicht an .Net oder WPF stören) ist hier. Nicht zu kompliziert aber auch nicht zu flach (wie die meisten Beispiele)

Ja, danke, sieht nach erstem Überfliegen gut aus. Werde ich mir morgen mal ausführlich ansehen.

[Lemmy]

wenn es dir nicht so unter den Nägeln brennt: Nick Hodges wird am 19.8. in den "Developer Skill Sprints Webinars" in Delphi ein MVVM in 20 Minuten erläutern:
http://forms.embarcadero.com/Develop...01G0000000tKTx

Teilnahme kostenlos.

Und dass es zum Thema ORM/GUI Anbindung und Delphi "wenig bis nichts" gibt ist so nicht richtig: Das Zeug versteckt sich leider nur sehr gut

Für die reine Datenbankanbindung würde ich eines der aktiven ORMs verwenden (DORM, tiOPF, InstantObjects oder Kaufware von Devart oder TMS) - bzw, wenn es denn sein muss eines selbst aufbauen (wobei man den Aufwand nicht unterschätzen darf).

Für die Oberflächenanbindung habe ich bisher das MGM-Pattern (Model-Gui-Mediator) verwendet, bin aber schon sehr gespannt auf den MVVM Vortrag von Nick....

[Harry Stahl]

Danke für den Webinar-Tipp. Werde zu den genannten Tageszeiten eher nicht können, aber vielleicht gibt es das ja später noch zum Download.

Habe von Malcom Groves ein interessantes Video zu MVVM mit gefunden:

https://www.youtube.com/watch?v=Ci1HP8ZBJxk

Wenn man übrigens nach MVVM (und Delphi) sucht, findet man das eine oder andere auch hier in der DP und im Netz.

[Sir Rufo]

Zitat von Harry Stahl:

Habe von Malcom Groves ein interessantes Video zu MVVM mit gefunden:
https://www.youtube.com/watch?v=Ci1HP8ZBJxk

Ja, das Beispiel ist extra so flach gehalten, damit die fehlenden Teile nicht auffallen.

Für die Bearbeitung eines Datensatzes in einem Modal-Dialog braucht man kein MVVM und wenn man dann von dem gezeigten Beispiel ausgehend weiter machen will (kann doch nicht so schwer sein, geht doch, hatta ja gezeigt) dann werden die Gesichter immer länger.

Wie gesagt, für diese PillePalle-Schmalspur-Augenwischerei reicht es, für eine Anwendung nicht.

Schau dir die "simple" Anwendung von der MS-Seite an, die auch relativ flach ist, im Vergleich zu dem was MG da zeigt, sind das aber die Alpen.