After a little researching (not much free time recently) I’m dropping the ActiveRecord idea for the moment. There seem to be a few problems with it. Mainly its a confused idea – many implementations rely on gathering database table and field metadata at runtime (i.e. it queries the database on every object instantiation) leading to performance issues, others do the same but cache the results (still an extra step), and overall this thing eats memory and noticeably slows PHP requests.

There are other confused ideas you can come across looking this up – ActiveRecord is a misnomer (its not identical to Fowler’s ActiveRecord design pattern but subtly different), it duplicates all “getter” methods across all objects (no abstraction of the data access component), and the list continues. Its well hyped – but has some serious flaws in most implementations I’ve seen so far. Although easier to use (everything is setup dynamically) its just more sensible to generate a bunch of DAO classes and be done with it. Oddly even the Zend Framework came under recent scrutiny – their own implementation of ActiveRecord was demonstrated via a webcast using a use case, which is currently not possible in PHP (see comments) except maybe with some imaginative acrobatics., leading the rumours it may not even exist yet…

The idea itself is very nice – but it needs a more focused implementation. At present ActiveRecord is not looking suitable for a small project looking for efficiency and speed. Its easier – but at a cost.

As such I’m back to my original plan of extending the Data Access system. This will (as at present) separate the actual data (a Transfer Object) and the data access methods (a DataAccess Object in the manner of the TableDataGateway pattern). The standard DAO will be extendable by a table specific Domain Object – i.e. very specific SQL operations not covered by the generic DAO methods.

Of course in keeping with the wanted update there’ll be a few improvements – DAO should be a base class with generic Access methods. The Transfer Objects will see some change to make them more useable in a generic system (previously there was a DAO for every table rather than a generic type). TOs will also be classified as “dynamic data”. That’s not specifically true (they only require a one time code generation run) – but for convenience they’ll be stored in the /Data/ directory – this is the main writeable directory setup during Partholan installation – so limiting these here will allow a greater level of automation for developers/users adding modules using their own specific database.

TO’s will also receive a status flag – so update/insert will be merged to a single save() method. I may also track changes – limit the possibility of multiple redundant updates occuring in error (a nightmare if it does).

Related posts:

  1. ActiveRecord for Partholan
  2. Data Access Objects – The Revisit
  3. PurpleAJAX