• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

db method return type: object array or Vector?

 
Matt Dole
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i have a method that needs to return a collection of objects, say Customers. each row of a table represents the fields of the Customer object. performancewise, is it better to have the method return an array of Customers (ie Customer[]) or a java.util.List/java.util.Vector containing Customer objects?
I personally like the method returning Customer[] because it makes a cleaner method signature.
since i don't know the number of objects that will be returned beforehand (size of array to allocate), i could do 2 queries: select count(*) and the data gather query. Alternatively, i could use 1 query, make a List, then call List's toArray(Object[] a) method. Is there major overhead with that method?
How do you guys deal with methods that return objects created from db queries?
 
Adam Hardy
Ranch Hand
Posts: 567
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Matt Dole:
i have a method that needs to return a collection of objects, say Customers. each row of a table represents the fields of the Customer object. performancewise, is it better to have the method return an array of Customers (ie Customer[]) or a java.util.List/java.util.Vector containing Customer objects?
I personally like the method returning Customer[] because it makes a cleaner method signature.
since i don't know the number of objects that will be returned beforehand (size of array to allocate), i could do 2 queries: select count(*) and the data gather query. Alternatively, i could use 1 query, make a List, then call List's toArray(Object[] a) method. Is there major overhead with that method?
How do you guys deal with methods that return objects created from db queries?

In comparison to the performance of the DB connection, passing back an array of objects or an object is going to make negligible difference.
I'd try to avoid doing two hits on the DB. Your solution sounds totally reasonable. I am actually trying to figure out a new design for my db access classes and I was looking at Core J2EE Patterns' Data Access Object and at Martin Fowler's site on Enterprise Application Architecture ( http://martinfowler.com/ ) but nothing really goes into the nitty gritty stuff.
My current db access classes return CachedRowSets which can be disconnected without dying, and the class conveniently has a .size() method.

Adam
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic