Hi,
I'm to refactor a web application that makes heavy use of good(?) old
JDBC calls to persist and retrieve data from an Oracle DB. The application features something called "Excel export" where users can select attributes to be exported. The generated Excel sheet has very simple looks, it's really nothing more than a table.
The mechanism I'm worried about is not the Excel sheet at first hand but the way how selecting wanted or unwanted attributes works: the user selects more or less directly column names from a DB view that contains all the data in question, his selections are concatenated to plain SQL and executed. The user doesn't know what really happens in the background, of course. Apart from the attributes/colums themselves the user can choose to order the exported data, this translates into an additional GROUP BY clause in SQL.
If the exported data was more static I'd usually do this with something like an export bean holding all the data and handing the bean to an Excel export service. Now it's getting more tricky with an unknown number of user-selected attributes, my first shot was to design a "mega bean" having all possible attributes and setting values where they exist, but his is ugly if only a few attributes are selected because I have to do a null-check whenever accessing a member.
So my question is: are there any design
patterns out there for a problem like this?