[CompInaBox-discuss] Object/Relational Mapping layer under development....
Brought to you by:
ericnielsen
From: Eric D N. <nie...@MI...> - 2006-05-03 19:56:52
|
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 |