After sitting on it for a few days, the basic idea of that Data Access update I mentioned in an earlier post has come together. What I have at the moment is an ActiveRecord version which does not require a huge level of change to what already exists. The changes will make a few things easier.

CRUD methods will now be directly linked to individual RowData level objects, for example. The API objects will still be required – but it makes things more intuitive. It also means a standard method of SQL generation can be imposed – not a huge task given ADOdb-Lite’s own shorthand methods. It also neatly moves any repetitive methods to a common parent class.

A short example:

REM: Character extends ActiveRecord

$char = new Character();
$char->setCharName(‘Maugrim’);
$char->save(); // ID (primary key) now set

$ship = new Ship();
$ship->setCharId( $char->getCharId() );
$ship->save();

There will also be more common methods to track which objects are changed (we should not be writing changes to database for records which have NOT changed!). Some standard queries, typically once off queries (more should be added to the API), can be run via a similar mechanism. This does however mean we need to have support for object collections.

$ship = new Ship();
$ship->setStarId(20);

$collection = $ship->getAll(); // return array of objects representing all ships at SS 20.

No man is an island – and I liberally borrowed from other sources of course. The internal code generator does differ however since I use ADOdb-Lite rather than a PEAR sourced or other 3rd party package. I also have my own personal quirks about how this should work – I really do not need anything complex – only a minimal implementation.

Structure:

ActiveRecord—->RowRecord{Character, Ship, Fleet, etc.}

API—->TableAPI{Character, Ship, etc., frequently used domain logic in methods}

DataAccessGateway {referenced by API and RowRecord}

Some of the quirks are obvious. RowRecord is identical to TransferObject, properties can be accessed directly or via accessors (preferred). ActiveRecord relies heavily on ADOdb-Lite.

DAGO is still a separate class, within the BusinessObject API. This could change, depending on how complex its SQL is, and whether it can be rewritten via an ActiveRecord method.

The big question is what difference this makes? Well, its easier to maintain, the relevant subclasses can be auto-generated very easily (though only with MySQL – ADOdb-Lite is missing the ADOdb Meta Information API which is a shame unless I resort to parsing the XML for the schema (not a bad idea for new database tables by module authors).

Plus I learned more about ActiveRecord – not a very familiar term.

Related posts:

  1. Another ADOdb Update
  2. Partholan 0.09 Progress
  3. Data Access Objects – The Revisit