I have two proposals to extend ezcPersistentObject that i wanted to share
with
the list. Both proposals are very non-invasive to the current code of
ezcPersistentObject and offer a great chance to extend its functionality
without fiddling in the current code-basis.
============================================
1st proposal: Implement Repository Pattern
Implementation of a repository pattern in conjunction with
ezcPersistentObject
is only a very simple step and can provide a huge benefit.
Requirements of a new ezcPersistentRepository class are
ezcPersistentSession and its corresponding ezcPersistentDefinitionManager,
best implemented through a getRepository() function on the
ezcPersistentSession.
A ezcPersistentRepositoryCriteria object may be created from the repository
that allows the specification certain conditions that an object has to meet
like:
$criteria->add('person_name', 10);
$criteria->add('person_age', new
ezcPersistentCriteriaDateRange('1820-01-01', '1911-01-01'));
$repository->query($criteria);
This criteria object is given back to the repository object, which then
creates the ezcDbSelectQuery object from the criteria and the information
of the definition manager.
The resulting ezcDbSelectQuery is handed down to ezcPersistentSession and
all the matching objects are returned from the repository in an collection.
Optionally a method could be provided that returns one and only one
matching
object and throws an exception if a.) 0 b.) > 1 objects are found.
It maybe useful to proxy all other calls to repository to the persistent
session so that an application designer has the possitibilty to require
a controller to speak with the repository only.
Additionally it should be supported to extend the ezcPersistentRepository
to that any programmer can move often used queries into the repository for
convenience.
=========================================
2nd proposal: Extended ezcPersistentObject Interface for Auto-Relation
support
An extended interface to ezcPersistentObject that offers the automatic
retrieval of related objects based on either a lazy load or a direct
loading
mechanism.
Two new functions should be required by this interface
ezcPersistentObjectWithRelations
setRelations(array $relations) and getRelations(). Set relations is given
the class name
of the related object with an collection/array of matching objects to that
relation. getRelation
retrieves the related objects for cascaded updating/inserting.
This might create some enourmous select/insert/update overhead that should
be fought by
the following mechanisms:
1.) Marker interface ezcPersistentObjectLazyLoadRelations, which when
detected returns
a ezcPersistentObjectLazyLoadCollection for all relations of the
implementing record.
The lazy load collection is given a php callback with the session object
and the required parameters to load the objects upon the first request of
the collection,
for example inside the load handler one would call:
// old code:
$object->setState($state);
// additional code to fetch related objects
$callback = array($session, 'getRelatedObjects');
$args = array($object, 'RelationName1');
$collection = new ezcPersistentObjectLazyLoadRelation($callback, $args);
$relations = array('RelationName1' => $collection1, 'RelationName2' =>
$collection2, ...);
$object->setRelations($relations);
the collection implements countable and iterator and when one of the
methods of those interfaces is called, the callback is invoked to lazy load
all the required objects. The collection also has a public method
"wasLazyLoaded()" that the persistent session might use to check wheater
the objects have been loaded at all and therefore don't have to be updated.
2.) a new interface ezcPersistentObjectModificationStatus that has a method
"wasModfied()"
with boolean return value. If the save handler of ezcPersistentObject is
invoked this interface
can be checked before inserting/updating the record.
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
