Allgemeine Informationen (FireDAC)

Aus RAD Studio
Wechseln zu: Navigation, Suche

Nach oben zu Architektur (FireDAC)

FireDAC hat eine flexible, leistungsstarke und erweiterbare Architektur.

FireDAC-Architecture.jpg

Allgemeine Informationen

FireDAC verfügt über eine lose verbundene mehrschichtige Architektur, in der Dienste von Schichten bereitgestellt werden. Eine Dienst-API ist als COM-Interface definiert, das von anderen Schichten über den Interface-Generator angefordert werden kann.

Wird keine Interface-Implementierung gefunden, wird eine Exception ausgelöst. Um die Implementierung in eine Anwendung einzubinden, muss die zugehörige Unit ebenfalls eingebunden werden. Diese Implementierungen können obligatorisch oder optional sein, und Sie können unter alternativen Implementierungen auswählen.



Beispiel

Das Interface IFDGUIxWaitCursor definiert beispielsweise die API für den Mauswartecursor (Sanduhr). Dafür gibt es drei alternative Implementierungen (Provider):

  • FireDAC.VCLUI.Wait – diese Unit enthält die Implementierung für VCL-GUI-Anwendungen.
  • FireDAC.FMXUI.Wait – diese Unit enthält die Implementierung für FireMonkey-GUI-Anwendungen.
  • FireDAC.ConsoleUI.Wait – diese Unit enthält die Implementierung für Konsolenanwendungen.

Eine GUI- oder Konsolen-Implementierung des Mauswartecursors ist obligatorisch und muss immer in die Anwendung eingebunden werden. Andernfalls wird die folgende Exception ausgelöst:

Object factory for class {3E9B315B-F456-4175-A864-B2573C4A2201} missing.
To register it, you can drop component [TFDGUIxWaitCursor] into your project

Hinweis: In der Exception-Meldung wird die Unit angegeben, die in Ihr Projekt einbezogen werden muss, damit die Standard-Interface-Implementierung eingebunden wird.

Nicht sichtbare Komponenten [Comp]

Die Schicht mit den nicht sichtbaren Komponenten [Comp] repräsentiert die public-Interfaces von FireDAC als nicht visuelle Delphi-Komponenten, vergleichbar mit anderen Datenzugriffskomponenten von Delphi. Die Schicht enthält Komponenten, wie TFDConnection (stellt die Verbindung her), TFDQuery (führt die Abfrage aus), TFDStoredProc (führt die gespeicherte Prozedur aus), TFDMemTable (Datenmenge im Arbeitsspeicher), TFDScript (die SQL-Skript-Engine) usw.

Die Haupt-Units sind:

Sichtbare Komponenten [GUIx]

Die Schicht mit den sichtbaren Komponenten [GUIx] ermöglicht die Interaktion zwischen Endbenutzer und FireDAC-Anwendung. Diese Schicht besteht aus einer Reihe von High-Level-Komponenten, mit denen die Dialogfelder für Standard-Datenbankoperationen, wie Anmelden oder Warten auf eine Operation, hinzugefügt werden können. Die Schicht enthält Komponenten, wie TFDGUIxWaitCursor (Wartecursor), TFDGUIxLoginDialog (Anmelde-Dialogfeld), TFDGUIxErrorDialog (Fehler-Dialogfeld) usw. Die Schicht stellt Implementierungen für folgende Plattformen bereit: VCL (VCL), FireMonkey (FMX) und Konsole (Console).

Die Haupt-Units sind:

Lokaler Datenspeicher [DatS]

Beim lokalen Datenspeicher [DatS] handelt es sich um eine Implementierung von Local Data Storage, die der von ADO.NET-DataSet und den zugehörigen Objekten (DataTable, DataRow, DataView usw.) entspricht. Der lokale Datenspeicher ist eine Daten-Engine im Arbeitsspeicher, die alle Client-Daten und Metadaten speichert und behandelt. Sie hat eine flexible API, die die Verwendung von DatS in Anwendungen ermöglicht.

Die Haupt-Unit ist:

  • FireDAC.DatS

Datenadapter [DApt]

Der Datenadapter [DApt] ermöglicht sowohl die Automatisierung und Optimierung von Leseoperationen mit komplexen Ergebnismengen (Haupt/Detail, verschachtelt, ADT usw.) als auch das Eintragen von Aktualisierungen in das Datenbanksystem. Der Datenadapter wird hauptsächlich durch die Eigenschaften TField und UpdateOptions gesteuert.

Die Haupt-Units sind:

  • FireDAC.DApt.Intf
  • FireDAC.DApt

Debug- und Leistungsmonitor [Moni]

Der Debug- und Leistungsmonitor [Moni] repräsentiert die Debugging-Funktionen von FireDAC, die Debug-Monitor-Interfaces implementieren. Diese Interfaces ermöglichen die Überwachung und Ablaufverfolgung von Interaktionen zwischen der FireDAC-Anwendung und dem Datenbankmanagementsystem (DBMS). Die Überwachung wird durch die Komponenteneigenschaften von TFDMoniXxxxClientLink und den Verbindungsdefinitionsparameter MonitorBy gesteuert. Der Monitor umfasst Komponenten, wie TFDMoniRemoteClientLink (Überwachung mit FDMonitor), TFDMoniFlatFileClientLink (Ablaufverfolgung einer Datei), TFDMoniCustomClientLink (benutzerdefinierte Ablaufverfolgung).

Die Haupt-Units sind:

  • FireDAC.Moni.RemoteClient
  • FireDAC.Moni.FlatFile
  • FireDAC.Moni.Custom

Treiber-API [Phys]

Die Treiber-API [Phys] definiert die Interfaces für den physischen Datenzugriff. Diese Interfaces werden in separaten Paketen als Treiber implementiert. Jedes Treiberpaket gehört zur Phys-Schicht und implementiert die erforderlichen Interfaces mittels der entsprechenden DBMS-API. Einzelheiten finden Sie unter Datenbankkonnektivität.

Die Haupt-Units sind:

  • FireDAC.Phys.Intf
  • FireDAC.Phys

Standardmäßig ist keiner der Treiber in die Anwendung eingebunden.

Native Treiber [Phys]

Die nativen Treiber [Phys] implementieren den Zugriff auf ein DBMS mittels einer Hochleistungs-Low-Level-API, die vom DBMS-Hersteller empfohlen wird. Sie passen die DBMS-spezifischen Funktionen genau an die FireDAC-API an. Alle nativen Treiber wurden für ein DBMS getestet und optimiert. Sie enthalten TFDPhys<DBMS>DriverLink sowie Dienstkomponenten.

Die Haupt-Units sind:

  • FireDAC.Phys.<DBMS>Wrapper
  • FireDAC.Phys.<DBMS>Meta
  • FireDAC.Phys.<DBMS>:

Brückentreiber [Phys]

Brückentreiber [Phys] implementieren den generischen Zugriff auf ein DBMS über generische Datenzugriffs-APIs: ODBC und dbExpress. Die Brückentreiber verwenden vom Treiber bereitgestellte Informationen bezüglich der DBMS-Funktionen. Diese Informationen decken nicht alle DBMS-Funktionen ab, die für FireDAC wichtig sind. Sie enthalten TFDPhysODBCDriverLink (ODBC-Treiber) und TFDPhysTDBXDriverLink (dbExpress-Treiber).

Die Haupt-Units sind: