A C++ DAL / ORM code generation framework
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 

56 lines
3.5 KiB

Design Architecture for WORM
This document describes the basic architecture for a DAL and ORM layer.
This is a general treatment and unfinished.
The database abstaction layer consists of four functional components that share one point of
entry to the database (via. the driver).
1. Classes which offer and API for basic CRUD interaction with the database.
These include:
* WSqlDatabase - the sole point of access recommended; all raw/direct interaction with
the database should use an instance of this class - the API is intended to provide any
direct query actions, insertions, selection of datasets, etc.
* WSqlDriver - this is a base class to be implemented by adapters for specific datastore
engines (currently MySql5, Sqlite3 and PosrgreSQL adapters are implemented). This class
does all the heavy lifting behind the scenes for the WSqlDatabase API. It should not be
used directly.
* WSqlRecord - datasets (or result sets) are encapsulated by WSqlRecord; this class is
returned by the API for queries that return results (may be empty ..) - it is initialized and
managed by the driver which hands it to WSqlDatabase. Random access to sets of the
records is supported (if cached). This is also the prefered method of insertion or update
- an initialized WSqlRecord sent to the driver is the cleanest interaction.
WSqlRecord is basically a vector of WSqlFields with some convenience methods for seeking
in the columns.
* WSqlField - represents a single data column in a record consisting of a column name
and a value (ie. simple key/value data structure). It does _not_ contain metadata about
the value. The value is stored as a string of characters as received from the database.
The value can therefor be easily converted to native C++ data types using the convenience
methods provided.
This class is intended to provide a simple and efficient data transfer - not metadata; if
metadata about the database column, data type etc. is needed WSqlColumn is to be used.
* WSqlResult - this class represents a set of returned records (or records to be inserted/updated)
it is an internal managed cache object for the driver.
2. Classes which offer and API for obtaining metadata about the database schemata. These may
instantiated for access to metadata at runtime but are primarily for use by the ORM generator.
These include:
* WSqlCatalog - access to all schemata in the DBMS (unimplemented)
* WSqlSchema - access to a metadata for a single database
* WSqlTable - metadata for a single table
* WSqlColumn - metadata for a single column
* WSqlIndex - metadata for an index in a table
* WSqlForiegnKey - metadata for a foriegn key relationship
3. Classes which deal with generating ORM class object source code representing the metadata
for existing database schemata.
These include:
* TBD
4. Generated ORM classes and scaffolding providing an alternate CRUD vector. These class
object may be used directly for CRUD functions with no interaction with the DAL classes.
Eg.:
user = new User(); user->setName("joe"); user->save();
or
int id = 33; user = User::load(id); cout << user->name();