Hi Benjamin,
On 01/06/2009 05:27 AM Benjamin Eberlei wrote:
> ============================================
> 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.
I like the idea of having a repository pattern implemented in ezc.
However, I'd suggest to make it a new component instead. The repository
pattern is nice to abstract the way data is stored at all, so it makes
sense to think about alternative back-ends for it in the future. I could
imagine file system storage or CouchDB as examples.
Would you like to make up a real proposal (aka requirements document)
for such a component?
> =========================================
> 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 is not a good idea, since it binds storage functionality to models
(aka "active record"). The basic idea of persistent object is, to leave
the decision to the user and his application architecture, where he
performs storage logic. If you prefer to use an active record way of
doing so, you can easily relize it in your application.
Regards,
Toby
--
Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards
Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer
t...@ez.no | eZ Systems AS | ez.no
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
