I have a couple of entities that can be searched for using a combination of parameters. The session facade has a finderXXX() method for each of the valid combinations.
What I'm finding is, as the number of candidate finder parameters increases, the number of finderXXX() method combinbations grows depending on the combinations that can be used.
For example, with 2 parameters A and B I have findByA(), findByB(), findbyAB(). Add a new parameter, C, to the mix and we get 4 new methods (C, AC, BC, ABC combinations). Maybe this over states the problem since perhaps not all combinations are valid, but you see my point.
So I was thinking of switching to a "find by example" interface, where I pass a class that holds the various find criteria (the example) and pass that to a single finder say, findByExample(ExampleClass myExample).
This would reduce coupling and increase cohesion by keeping the "valid" search combination login in the session/entity implementation rather than externally by the callers method selection.
I was wondering what everyone else thought? Has anyone implemented this type of finder strategy? Can anyone suggest an alternative approach?
How about using CMP along with O/R mapping tool
like TopLink or Cocobase?
I used a similar kind of tool inbuilt within that
container and does a fantastic job of generating
fonder methods on specified fields and also by the
range. It also generates finder methods to traverse from
one entity to other in one to many relationships.
I see you delimma. I think you can solve this problem by using your session bean to build the search string dynamically. Specfically, base on the ExampleClass's attributes, you can build the sql query string that works for all combination. This strategy reduce the need to have several finder methods. In addition, this strategy is more scalable.
Hope this helps.
Yes, this is what I was thinking too. A "fast-lane reader" pattern implementation using dynamically constructed SQL queries.
We faced an identical problem and went with a strategy just as you describe it. We have a interface, FinderCriteria, that is implemented by several different classes, depending on the SessionBean that is using it.
For example, our MemberSessionBean has a findMembersBy method that takes a MemberFinderCriteria as a parameter.
On the back end, we have defined a mapping that maps from this Criteria to either DB columns or CICS fields.
So far, it has worked quite well, as the clients only need to fill out the criteria they are interested in and invoke the method.