Adrian Crum wrote: > David, > > I've been thinking about this more. Here are a couple of ideas I came up > with: > > 1. Move the existing delegator cache maintenance methods to a separate > interface+class. Add a method to DelegatorInterface that retrieves an > instance of the class for peripheral code to work with. End result: +1 > cache maint class, +1 delegator accessor method, -14 delegator cache > maintenance methods.
I've thought this too. So all delegator calls would be wrapped, effectively, and do cache storing. The code in entity/cache has some algos that could be used for this. They take their parameters, convert them into a 'key', and use that for access. > 2. Reduce all of the findByXxxx and findAll methods to a single find > method that takes a FindParameters class. A separate worker class could > convert all of the various arguments currently being sent to the myriad > findXxxx methods and condense them into a FindParameters instance that > is passed to the single find method in the delegator. End result: +1 > find parameters worker class, -23 delegator methods. In effect, that's what already happens; most code eventually calls findByCondition. Additionally, this could simplify the sql generating parts too.
