Hello everyone, 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. 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 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 greetings, Benjamin -- Benjamin Eberlei http://www.beberlei.de -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
