Hi Benjamin, On 03/29/2009 10:57 AM Benjamin Eberlei wrote:
> I opened up an issue on ezPersistentObject to break up dependencies between > the session and the 3 handlers load, save and delete. Currently their usage > is > only for internal reasons, but they offer huge optimization and extension > points. > Additionally despite the refactoring they are still to big in my opinion and > additional features would only increase the handler classes, which would take > up to many responsibilites. > here is the ticket: > http://issues.ez.no/IssueView.php?Id=14689&activeItem=4 > My use case for this break up is the following: > > Data Mapping is quite a complex task and having generic load, save, delete > components is not always the best way out in terms of performance or features > and the single responsibility principle of OOP. > > I want to swap a delegate handler into the play, which based on the $class > attribute decides which specific handler to call. This way I can build my own > handlers for any entity that has performance issues or needs more special > features. > > All the other entities could still use the shipped ezc handlers and benefit > from its functionality. Regarding this ticket: I'm not sure if giving handler delegates to the session is a wise idea. The intention behind the handlers was to simply split the very large code base of ezcPersistentSession into smaller parts, which can better be overlooked. Therefore the handler classes are marked as private by now, since the user is not intended to use them dedicatedly. In addition, adding the handler instances as optional parameters makes the interface bloated. There are only few use cases where it makes sense to replace a handler. I could imagine that we outsource the handler construction in the session into their own protected methods, though. This way you can extend ezcPersistentSession and overwrite these methods to create custom handlers. Would that be a satisfying solution for you? > For future versions of ezc there are additional benefits of this change: > > * New features like inheritence mapping or optimistic locking can be added > into specific sub-class loaders and savers so that the already existing code > does not get longer and more complex. > * Performance Based Loaders with Association-Table-Mapping could be added > into > specific loaders that fetch an object and one ore more relations with one > single select query and build them together correctly. > * Use of Handlers should then be (optionally) configurable via > ezcPersistentObjectDefinition I need to think about more about such things, since they were not in scope of PersistentObject, yet, and I'm not sure how soon this will come. I don't want to take the big step of making the internal handlers public now and provide interfaces for them, before we come to the point we really need them. This would result in loosing the opportunity of breaking the handler API. > This also affects the following issues: > http://issues.ez.no/IssueView.php?Id=13127&activeItem=29 > http://issues.ez.no/IssueView.php?Id=13264&activeItem=27 > http://issues.ez.no/IssueView.php?Id=13177&activeItem=26 I'd like to see the features named in this issue, too. However, it won't happen for the next release. Therefore we'll look at them again after that. Best 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
