Is this DAO method too complex?

Question

Below is a method that I want to implement for my Machines DAO class, which queries the database for machine tuples matching the specified criteria (xxxIs parameters) and returns only the projected columns (getXXX parameters). This method is designed specifically to support a search screen in my interface, which allows the user to specify the set of columns to view/retrieve (to limit network overhead) and the search criteria.
Collection findMachines(boolean getMachineID,
                             boolean getMachineName,
                             boolean getStatus,
                             boolean getExpirationDate,
                             boolean getPurchaseDate,
                             boolean getPurchasePrice,
                             boolean getOwnerName,
                             boolean getLastModifiedByID,
                             boolean getLastModifiedByName,
                             boolean getLastModifiedAt,
                             boolean getSectionID,
                             boolean getSectionName,
                             boolean getPlantID,
                             boolean getPlantName,
                             String machineTypeIs,
                             String machineMakerIs,
                             String machineModelIs,
                             String machineNumberIs,
                             String statusIs,
                             String sectionIDIs,
                             String plantIDIs
                             ) My question is:
1. Most of the DAO examples I've seen contain simple find methods with one or two paramters. But in my code, I often find the need to create a complicated find method like the one above to support flexibility in the user interface and provide better performance (doing a single SQL query instead of mulitiple ones). Nonetheless, these complicated find methods seem very inelegant, so is there a better way?
2. The Value Object returned by such method would contain several null fields for columns that are not projected. Furthermore, several attributes in this Value Object are there only to support display columns in the user interface, and are not needed by other parts of the system. This seems quite inelegant to me.

Answer 1

eyilin, you may either consider yourself lucky or unfortunate, as I'm in a loquacious mode this evening. I'll going to take your questions in reverse order.
2) Your VO should reflect the underlying data, not necessarily the other way 'round. Yes, database calls are "expensive," but you can throw away whatever you've gained using the reduced-set queries by moving through convoluted conditionals in an attempt to not "waste" data (non-used fields). You say the user display portion will not need certain fields for certain displays. So what - you're either going to ignore a null or a occupied field. There's no difference there. What happens if you need to change the display to add a field? Now, you have to change the call to the persistence layer, as well. If you already had the data, you'd just change the display code.
1) Do not try to make a single persistence layer method "one size fits all." As above, you'll end up blowing more time (both in writing the durn thing, as well as code-execution) than you think you'd save. If you need specific "finders" for specific parameters, each one is a separate method: findByMachineId, findByMachineType, etc. Keep these methods together in one class, for sure. That way they can share certain repeated code blocks, like a single private MachineVO resultSetToVO(ResultSet rs) - which is where #2 comes into play. If you need to narrow results for display purposes, you don't necessarily need to go back to the database - you already have the data; just select a subset to display (this can be done in the for loop constructing the display). Need to drill in to a single MachineVO? You've already got it - so just display it.
Finally, to be quite frank, your single method call will be guaranteed to be an absolute nightmare to maintain. Part of the big deal with maintenance is that it helps if it makes semantic sense. Two examples:
Example 1:
Collection machines = findMachines(true,true,true,false,true,false,false,false,
      false,false,false,false,false,false,
      null,null,"THX1138",null,null,null,null);
Example 2:
MachineVO[] machines = findByModel("THX1138");You'll find it quite unlikely that you'll need methods like findByModelPlantAndOwner.