Win a copy of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 this week in the Java in General forum!
  • 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:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

Regarding Good OO Design

 
Ranch Hand
Posts: 110
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic