There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
"A POJO that represents a table with 30 columns" can be a design smell and I would revisit that design choice if I were you. I'm not saying it's wrong necessarily but like I said before, it's not always the best way to map objects to database entities. To answer your question, it depends. What are you going to use the Strings for? After you reconstitute them back from the database, do these Strings have any relationships with other objects in your program that will need to be re-established or will be you be dealing with the list of Strings purely on their own? If the latter, then returning a list of Strings from the DAO is probably fine. If there are interesting relationships that need to be re-established with other objects in your program, then the DAO should be responsible for doing that and you would probably be better served by returning a list of objects.Tscharner Upjohn wrote:So if I have a POJO that represents a table with 30 columns and will get a result set of x rows but just one column of Strings should I really create x objects of that class or does it make more sense to just return the List<String>?
In my experience, it's best to avoid "generic" DAOs. Write a DAO for each significant object or set of related objects that have data/relationships that can be mapped to one or more database tables.If the latter how do people handle that in a generic DOA? All examples have a DOA class created for each table object.