Regarding Good OO Design

[James Gordon]

Hi,
I have an object which represent a row from a table. After selecting from the database, I would
loop through the ResultSet and set the values of
each column to this object. Then, they would be
added to an ArrayList.
My question is on whether it is a good design to
place the method to select the ResultSet from the database in this object itself? Or should I create a separate object which act as a helper
and have the method as static?
Please advice.
Thanks in advance.

[Alain Boucher]

Do not put the code in the Class... Their is no link between a Dog Object and a DB row. If your DB change you should not have to change your Dog object... So yes, use a Helper that use your object "setter" method to do that.

[Stan James]

Some chunk of code somewhere has to know how to map your relational stuff to your object stuff. It's good to isolate this knowledge into a persistence layer and keep it out of your business object model.
The persistence layer can implement some interface with create, retrieve, update, delete methods and hide all the db interaction. You should not see SQL, connections, statements, result sets from outside thsi layer.
Then if need be you could implement the same interface with another database or a file based system or calls to remote services or subliminal signals to friendly aliens or whatever.
Alternatives to writing this knowledge yourself are object databases or object-relational mapping products. O-R tools usually use meta-data that describes "this object attribute goes to this table and column". EJB has O-R mapping built-in in entity beans with bean managed persistence. TopLink is a commercial O-R product.
Ok, that went from a small rearrangement of your classes to a whole purchased architecture. Was any of it helpful?
[ April 11, 2003: Message edited by: Stan James ]

[Tim Lovern]

The concept we use is pretty straight forward. The row from the database would be represented in a Value Object (VO)
The data access would be handled by a Data Access Object (DAO).
The DAO would be aware of the VO, but not vice versa. The DO is basically all the columns from the query with a getter and setter method for each.
If you are using SUN's free IDE, it will generate the getters and setters for you automatically.
Right click on a variable, select tools, then select generate R/W property for field.
It will generate a getter and a setter method for the field.
If you need to return more than one row from a database, have the DAO return a collection of VO's.
Again, this keeps the separation of the data from the data source. You could simply write a new DAO for XML documents, and your application would not break.
Also, abstract your DAO's one layer by coding to an interface. Use the interface in your programs, not the actual DAO object. Then it is a no brainer to change implementations. Just use a factory to return an instance of the DAO (interface).
just a thought.
hope this was helpful...