[CompInaBox-discuss] Object/Relational Mapping layer under development....

[Eric D N. <nie...@MI...>]

Most of my efforts over the last week or so have been on creating a new
"Object/Relational Mapping" Layer.  If you're not familiar with this term it
refers to the code that handles "saving" regular Object-Oriented style objects
into a regular Relational Database system.  The two paradigms OO and RD are
designed for different uses and there's often a little bit of "juggling" to
accomplish to make a smooth transition, especially if both your Object Model
and your Data Model are non-trivial (and therefore likely very different from
each other).

I'm taking the approach of an "ignorant" but rich domain model and a "smart" ORM
layer.  Thus the Domain Model (classes like Competition, Event, Person, Couple,
etc) will loook like standard objects from an OO perspective.  They won't know
that there is a database behind them.  I'm endeavoring to make sure that
requirements from the ORM don't spill over into the Domain Model -- no
requirements for specific constructors, or specifically named getter/setters,
no requirements for a field to hold the database primary key, etc

The ORM layer will be slightly more complicated as a result, but 90% of that
complexity is already required in order to support the more flexible mapping
required before tacking on those requirements.  The ORM is modelled roughly
after Hibernate from the Java world; albeit greatly simplified at present and
with PHP-idioms applied as well.

Mapping files are currently in a "natural" languange syntax, not an XML format.
Mapping files are parsed when first needed by a script (they are not all loaded
on every request)
The ORM maintains an Identity Map that tracks primary keys to objects and vice
versa.  This Identity Map can be used to return previously retrieved objects
without hitting the DB a second time for the same object in one request. 
(Hibernate's first level cache, PHP's short lived scripts doesn't make
Hibernate's second level cache possible in any meaningful way).  The ORM also
saves a clone of the object to use for dirty field checking to avoid updating
un-needed fields (as the database is expected to have on update triggers
defined).

The ORM layer will be responsible for creating the connection(s) to the database
and restricting access to said connection to within the ORM module.

The ORM will support Lazy Loading of objects via creation of proxy classes at
run-time when needed.  (Ie when lazy loading is requested for a class, it first
checks for a Proxy version of that class, if not found, it checks for a file
containing a Proxy definition of the class with a timestamp after the last
modification of the real class, if not found it creates a file with a proxy
definition of the class and then loads it.  This proxy class acts exactly like
the real class, but won't access the database for its information until the
information is requested.)

For instance a Competition has a list of Events, each Event has a list of
Couples, each Couple has a list of Events, etc.

When a Competition Object is loaded, the EventList is initally proxied and not
transfered from the DB.  The Competition object is loaded on practically every
SlidingDoors page, but the actual events are seldom needed.  If a client of the
Competition object calls a method like ->getEventByName, or ->getEvents, then
the proxy gets loaded behind the scenes and the client "thinks" nothing unusal
happened and that the data was always there.

If anyone is interested in more details on the ORM layer, please let me know. 
If anyone is interested in a more "traditional" programming project (aka
non-web), this would be a great place to help out as its a more stand alone
component without some of the complicating web-concerns, but still complicated
in its own right.

Eric