I suppose this question is all a matter of interpretation of the requirement: "a flexible search mechanism". My thinking is that filtering GUI side is fine, but in the future if a search algorithm is required such that a piece of text is to be searched across all data field values, then I think a strategy + command pattern would minimize client side changes, keep a single call to the server and also keep the 'searching business logic' in the business layer rather than at the GUI. However I fear these extra class will go to waste if I'm interpreting the world "flexible" wrongly. By flexibly does it mean just "Name or/and Location" searching or flexibility in terms of future maintenance of search algorithms?
My search form has the ability to search for records on only name, only location, name and location or just return all records. My search form can be easily extended to add a search on date or size for example. No patterns used, just simple text fields which values are put in an array and send to the database to perform the search.
Although only just 2 fields are used to search on, my server is capable to search on every field (implementation was tested with a junittest case, just like all other methods from Data class).
It's definitely the more elegant approach. I suppose that if one wanted a search algorithm whereby they enter a piece of text and it searches throughout all data i.e. text, null, null, null, null, null; null, text, null, null, null, null; null, null, text, null, null, null .... null, null, null, null, null, text; then all 6 arrays can be called on the server. I'll state in my choices text this is sufficient for the task at hand and that the minor issues of maintenance and performance are outweighed by the more understandable approach.
SCJP 1.5, SCJD 1.6
The longest recorded flight time of a chicken is 13 seconds. But that was done without this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!