• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Return List<object> or List<String> with database query with just one column returned

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am trying to see what people say is the best practice for a particular issue. Most generic DOA examples I find and other database queries return into a POJO that represents the database, which makes sense except in the case where just one column will be returned. 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>?

If the latter how do people handle that in a generic DOA? All examples have a DOA class created for each table object.

Thanks for the thoughts and sorry if the terminology is not perfect please ask for clarification if it doesn't make sense.
 
Marshal
Posts: 28177
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's pretty hard to design a database table with only one column these days. Generally you're encouraged to use one column for an "ID" field which is going to be the key for the table, and then put your business-level data into the subsequent columns.

However, let's suppose you somehow avoided doing that. I would still want my rows to be represented by Java Beans, so that my JSPs could access the single column via a Java Bean property name, just like all of the other tables with more than one column. Otherwise you're asking the JSP writer to go out of their way to do something slightly different for this one oddball table.

(And as a general design and programming rule, I don't like to treat trivial cases differently than non-trivial cases. That's why methods which return an array should return an array with zero elements if they need to return nothing, rather than returning null, for example.)
 
Tscharner Upjohn
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Paul thanks for the thoughts. I think you said a table with one column, but actually i am referencing a query that returns just one column from a table so it might return a List<String>

I appreciate your answer and it makes sense. What I was wondering is there a memory versus ease issue? If I have a List<beans> is that something to worry about or is the programming ease of use more important do you think?
 
lowercase baba
Posts: 13089
67
Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am not an expert, but...

Generally, you spend about four times as much time maintaining your code as you do writing it. So, for this reason, you should write it to be as clear and clean as possible. Write what makes the most sense, and worry about speed/performance/memory later.
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Tscharner Upjohn
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Junilu: Thanks for the thoughts. You are correct I did mean DAO (Data Access Object), maybe my dyslexia was because some think my cod is DOA (dead on arrival). Can you give an example of or maybe some reference articles (as I work to improve my knowledge) on when the java object representing the table shouldn't contain all the fields of the table itself?

As for what I would do with the strings, what I have is a web form that has two drop down lists, one of client codes and one available report dates for the selected client. After selected the pair the user can run reports off that data. So instead of querying all possible data for these reports I just brought down the strings for the clients possible. Does that make sense what I have done or is there a better way?
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One example would be Order and LineItem. In objects, an Order will be related to zero to N LineItems. When persisting an order by saving it to a relational database, you would normally have two tables to read/write: Orders and LineItems. A DAO for Order could conceivably be written to read/write from/to both tables. That's one DAO mapping an Order and its subordinate objects into two tables.

I don't like to think of Java objects as representing tables, although you often end up with a design where there are many 1:1 correspondences between classes and database tables. I try to start with objects and their relationships to each other and build up the main design and functionality around the object model. Persistence and the database is on the periphery of my design process and it usually closely follows the object model and the relationships represented by it.
 
The harder I work, the luckier I get. -Sam Goldwyn So tiny. - this ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic