Hi all!
Beside some code-consolidations for the methods in ezcPersistentSession
(the main class of the PersistentObject component) I plan some
refactorings for this class. I wrote down my ideas in the (currently
pending) design document for version 1.4 (can be found in
trunk/PersistentObject/design/design-1.4.txt) and want to gather
feedback from you for it.
Find the specific section below:
ezcPersistentSession refactoring [#12287]
=========================================
Background
----------
The ezcPersistentSession class is the very heart of the PersistentObject
component. It contains the complete application logic of the component,
structured in many public (25) and a few protected and private (5)
methods consisting of more than 1200 lines of code and documentation.
The mass of code starts getting unmaintainable by now and some
code-synergies could be realized between different methods. Therefore a
refactoring of the class and its surrounding classes will be described
in this section to solve the named issues. The public API of
ezcPersistentSession will not be affected by this, but only delegation
might happen internally, without being visible to
the user of the API.
Design
------
To reduce the pure number of method implementations in this class, the
following new classes are suggested to group the functionality:
- ezcPersistentLoadHandler
- public function load( $class, $id )
- public function loadIfExists( $class, $id )
- public function loadIntoObject( $pObject, $id )
- public function refresh( $pObject )
- public function find( ezcQuerySelect $query, $class )
- public function findIterator( ezcQuerySelect $query, $class )
- public function getRelatedObjects( $object, $relatedClass )
- public function getRelatedObject( $object, $relatedClass )
- public function createFindQuery( $class )
- public function createRelationFindQuery( $object, $relatedClass )
- ezcPersistentSaveHandler
- public function save( $pObject )
- public function update( $pObject )
- public function saveOrUpdate( $pObject )
- public function addRelatedObject( $object, $relatedObject )
- public function createUpdateQuery( $class )
- public function updateFromQuery( ezcQueryUpdate $query )
- private function saveInternal( $pObject, $doPersistenceCheck = true,
- private function updateInternal( $pObject, $doPersistenceCheck =
true )
- ezcPersistentDeleteHandler
- public function delete( $pObject )
- public function removeRelatedObject( $object, $relatedObject )
- public function createDeleteQuery( $class )
- public function deleteFromQuery( ezcQueryDelete $query )
- private function cascadeDelete( $object, $relatedClass,
ezcPersistentRelation $relation )
These classes will just act as method containers. An instance of each
class will be held in a virtual-property of the ezcPersistentSession
instance. All will receive the ezcPersistentSession instance as a ctor
parameter, to be able to interact with it and the remaining classes.
The methods stubs of ezcPersistentSession will remain as they are,
dispatching to instances of the newly created classes, which will then
perform the actual work.
Some common methods will be left in ezcPersistentSession, defined as
public but marked as private (lack of friendship relations for PHP
classes). In addition, the code of the outsourced methods will be
consolidated into new, common methods (like executing a query and
checking the result, optional checks of getState() methods, ...) of
ezcPersistentSession, where possible.
Notes and ideas
---------------
This refactoring approach will obviously have an impact on performance,
since for each public method call on ezcPersistentSession there will be
an additional method invocation added. In addition, the consolidiation
of common code into helper methods (held on ezcPersistentSession) will
impact performance. On the other hand, the extraction of methods from
ezcPersistentSession into handler-classes will raise the maintainability
of the whole component and the consolidation of common code will reduce
the complexity of the implemented methods, which also raises
maintainability, code-reuse and error-tollerance. In addition, it makes
the implementation of new features easier.
An idea would be to instanciate the newly created handler classes only
when needed (via virtual-property checks), which would reduce the
ammount of code to load on instantiating ezcPersistentSession and the
memory usage occupied by objects.
Feedback is highly appreciated!
Best regards,
Toby
--
Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards
Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer
[EMAIL PROTECTED] | eZ Systems AS | ez.no
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
