I assume you meant DAO (Data Access Object), not DOA. A DAO is a way to bridge the so-called impedance mismatch between data/relationships as represented by objects and data/relationships as represented in a database, usually a relational database. A DAO does not necessarily need to have a 1:1 correspondence to a database table and in many cases it's not the best way to do it.
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>?
"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.
If the latter how do people handle that in a generic DOA? All examples have a DOA class created for each table object.
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.