> The idea of a query parameters object is interesting. If we do something like
> that we should look at some ways of reducing the lines of code required to
> use it. I think that's the only part of it I don't like... lots of lines of
> code.
This is a very crucial point in this thread.
A heavily parameterized method is great for genericity. We can call such a method with
programmatically generated parameters. Very consistent, very single-entry-point approach.
However, such a method will require "setting up" of the parameters before
calling it.
In comparison, having a few buttons named "chicken", "fish", "pasta" on a microwave oven will
allow me to just press the button for the common scenario I'm facing at the moment. I don't need
to think about how much heat a chicken can take, compared to a fish.
Jonathon
David E Jones wrote:
On Oct 19, 2007, at 9:24 AM, Adam Heath wrote:
Adrian Crum wrote:
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.
My original thought was to review these (23? wow...) methods and
deprecate (and later remove) nearly all of them. The main ones I think
should remain are:
1. a findListIteratorByCondition method with all possible parameters
2. a findByAnd method with all possible parms
... and I think that's about it for the finds. Both would have a new
parameter called "useCache". The findByAnd is just there for convenience
as that is a common use case.
The idea of a query parameters object is interesting. If we do something
like that we should look at some ways of reducing the lines of code
required to use it. I think that's the only part of it I don't like...
lots of lines of code.
Whatever the case, I think the most important thing is that we not rush
this. There are lots of less effective ways to do this (like the one we
have now...), so the key is to avoid introducing something that is just
as cumbersome/annoying.
-David
