AnyDAC
ContentsIndexHome
PreviousUpNext
General

AnyDAC has flexible, powerful and extendable architecture.

Group
Links

General

AnyDAC has a weakly coupled multi layered architecture, where layers may provide services. A service API is defined as a COM interface, that may be requested by other layers using the interface factory. 

When an interface implementation is not found, then an exception will be raised. To link the implementation into an application, the corresponding unit must be linked in. There may be alternative implementations and mandatory / optional implementations. 

 

Example

For example, IADGUIxWaitCursor interface defines API for the mouse wait cursor. It has the three alternative implementations (providers):

  • uADGUIxFormsWait unit contains implementation for the VCL GUI applications;
  • uADGUIxFMXWait unit contains implementation for the FireMonkey GUI applications;
  • uADGUIxConsoleWait unit contains implementation for console applications.

GUI or console mouse wait cursor implementation is mandatory and must always be linked into the application. Otherwise exception is raised: 

 

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

 

Note, the exception message suggests the unit to include into your project to link the standard interface implementation. 

 

Non visible Components [Comp]

The layer represents the AnyDAC public interfaces as Delphi non-visual components, similar to other Delphi data access components. It includes components - TADConnection (establish connection), TADQuery (execute query), TADStoredProc (execute stored procedure), TADMemTable(in-memory dataset), TADScript (SQL script engine), etc. The main units are:

 

Visible Components [GUIx]

The layer provides a way to interact with the end user from an AnyDAC 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 - TADGUIxWaitCursor (wait cursor), TADGUIxLoginDialog (login dialog), TADGUIxErrorDialog (error dialog), etc. Layer provides implementations for VCL / LCL, FireMonkey and console platforms. The main units are:

 

Local Data Storage [DatS]

The layer is a Local Data Storage implementation, which is analog to the ADO.NET's DataSet and its related objects (DataTable, DataRow, DataView, etc). It is an in-memory data engine, actually storing and handling all client data and meta-data. It has flexible API, allowing you to use DatS in applications. The main unit is:

  • uADDatSManager.

 

Data Adapter [DApt]

The layer allows automation and fine-tuning of a read operation with complex result sets (master-details, nested, ADT, etc) and allows posting updates back to the database system. It is controlled mostly through TField and UpdateOptions properites. The main units are:

  • uADDAptIntf;
  • uADDAptManager.

 

Debug and Performance Monitor [Moni]

The layer represents AnyDAC debugging capabilities by implementing debug monitor interfaces, which allow monitoring and tracing interactions between the AnyDAC application and the DBMS. It is controlled mostly through [ADSettings] parameters of ADConnectionDefs.ini and the MonitorBy connection definition parameter. It includes components - TADMoniRemoteClientLink (monitoring using ADMonitor), TADMoniFlatFileClientLink (tracing into file), TADMoniCustomClientLink (custom tracing). The main units are:

 

Drivers API [Phys]

The layer defines interfaces for physical data access. It implements them in separate packages as the drivers, where each driver package belongs to the Phys layer and implements the required interfaces using appropriate DBMS API. See Database Connectivity for details. The main units are:

By default none of the drivers are linked into the application. 

 

Native Drivers [Phys]

The native drivers are implementing access to a DBMS using a high performance low-level API recommended by the DBMS vendor. They precisely adapt DBMS specific features to the AnyDAC API. All native drivers have been tested and optimized for a DBMS. They include TADPhys<DBMS>DriverLink and service components. The main units are:

 

Bridging Drivers [Phys]

The bridging drivers are implementing generic access to a DBMS using generic data access API's - ODBC and dbExpress. The bridging drivers are using driver supplied information regarding DBMS features, which is not covering all DBMS features interesting to AnyDAC. They include TADPhysODBCDriverLink (ODBC driver), TADPhysTDBXDriverLink (dbExpress v 4 and higher driver), TADPhysDBXDriverLink (dbExpress v 1-3 driver). The main units are:

What do you think about this topic? Send feedback!