General (FireDAC)
Go Up to Architecture (FireDAC)
Contents
FireDAC has a flexible, powerful, and extendable architecture.
General
FireDAC has a loosely-coupled multilayered architecture, where layers provide services. A service API is defined as a COM interface that other layers can request using the interface factory.
When an interface implementation is not found, an exception is raised. To link the implementation into an application, the corresponding unit must also be linked. These implementations can be mandatory or optional, and you can choose from alternative implementations.
Example
For example, the IFDGUIxWaitCursor interface defines API for the mouse wait (hourglass) cursor. It has three alternative implementations (providers):
- FireDAC.VCLUI.Wait - this unit contains the implementation of VCL GUI applications.
- FireDAC.FMXUI.Wait - this unit contains the implementation of FireMonkey GUI applications.
- FireDAC.ConsoleUI.Wait - this unit contains the implementation of console applications.
A GUI or console mouse wait cursor implementation is mandatory and must always be linked into the application. Otherwise, the following exception is raised:
Object factory for class {3E9B315B-F456-4175-A864-B2573C4A2201} missing.
To register it, you can drop component [TFDGUIxWaitCursor] into your project
Note: The exception message suggests the unit that must be included into your project in order to link the standard interface implementation.
Nonvisible Components [Comp]
The Nonvisible Components [Comp] layer represents the FireDAC public interfaces as Delphi nonvisual components, similar to other Delphi data access components. It includes components such as TFDConnection (establishes the connection), TFDQuery (executes the query), TFDStoredProc (executes the stored procedure), TFDMemTable (in-memory dataset), TFDScript (the SQL script engine), and so on.
The main units are:
Visible Components [GUIx]
The Visible Components [GUIx] layer provides a way to interact with the end user from a FireDAC application. It is a set of high-level components allowing to add the end-user dialogs for the standard database operations, like a Login or a Wait-for operation. It includes components such as TFDGUIxWaitCursor (wait cursor), TFDGUIxLoginDialog (login dialog), TFDGUIxErrorDialog (error dialog), and so on. The layer provides implementations for VCL (VCL), FireMonkey (FMX), and console (Console) platforms.
The main units are:
- FireDAC.UI.Intf
- FireDAC.<platform>UI.Xxxx
- FireDAC.Comp.UI
Local Data Storage [DatS]
Local Data Storage [DatS] is a Local Data Storage implementation, which is analog to the the ADO.NET DataSet and its related objects (DataTable, DataRow, DataView, and so on). It is an in-memory data engine, which stores and handles all client data and metadata. It has flexible API, allowing you to use DatS in applications.
The main unit is:
- FireDAC.DatS
Data Adapter [DApt]
Data Adapter [DApt] allows both the automation and fine tuning of a read operation with complex result sets (master-details, nested, ADT, and so on) and the posting of updates back to the database system. It is controlled mostly through the TField and UpdateOptions properties.
The main units are:
- FireDAC.DApt.Intf
- FireDAC.DApt
Debug and Performance Monitor [Moni]
Debug and Performance Monitor [Moni] represents the FireDAC debugging capabilities that implement debug monitor interfaces, which allow monitoring and tracing interactions between the FireDAC application and the Database Management System (DBMS). It is controlled by the TFDMoniXxxxClientLink component properties and the MonitorBy connection definition parameter. It includes components such as TFDMoniRemoteClientLink (monitoring using FDMonitor), TFDMoniFlatFileClientLink (tracing into file), TFDMoniCustomClientLink (custom tracing).
The main units are:
- FireDAC.Moni.RemoteClient
- FireDAC.Moni.FlatFile
- FireDAC.Moni.Custom
Drivers API [Phys]
Drivers API [Phys] defines the interfaces for physical data access. It implements them in separate packages as drivers, where each driver package belongs to the Phys layer and implements the required interfaces using the appropriate DBMS API. See Database Connectivity for details.
The main units are:
- FireDAC.Phys.Intf
- FireDAC.Phys
By default, none of the drivers is linked into the application.
Native Drivers [Phys]
Native Drivers [Phys] implement the access to a DBMS using a high performance low-level API, which is recommended by the DBMS vendor. They precisely adapt the DBMS-specific features to the FireDAC API. All native drivers have been tested and optimized for a DBMS. They include TFDPhys<DBMS>DriverLink as well as service components.
The main units are:
- FireDAC.Phys.<DBMS>Wrapper
- FireDAC.Phys.<DBMS>Meta
- FireDAC.Phys.<DBMS>:
Bridging Drivers [Phys]
Bridging Drivers [Phys] implement the generic access to a DBMS using generic data access APIs: ODBC and dbExpress. The bridging drivers use driver-supplied information regarding DBMS features, which is not covering all the DBMS features that of interest to FireDAC. They include TFDPhysODBCDriverLink (ODBC driver) and TFDPhysTDBXDriverLink (dbExpress driver).
The main units are: