Jason C Puyleart wrote:
>
> hi.
>
> I've been writing objects using Java and C++ for a while now and have been
> running into the same problem repeatedly.
>
> Can someone point me to some books, reference materials, code, anything
> that cleanly separates the idea of object persistence from the objects. I
> don't think that my JDBC calls should be within the object but I don't
> really know of another way to do it.
>
> Also, are people using JDBC to map relational database information to
> objects or is everyone just using the result set object that is passed
> back? Are their any tools for doing this sort of mapping? (Do they
> support relationships, etc...)
>
> It comes down to the fact that I just want to write cleaner code, and I'm
> not sure quite how. Any help would be immensely appreciated. Thanks in
> advance!
The problem you have describe is a very common. How do you transform
flat information that you get out of a database into objects and then be
able to store changes to those objects back in the relational database?
There are many many answers. A lot of these answer involve various
design patterns. One of the biggest that describes how to handle this
problem is the Crossing Chasms pattern
(http://c2.com/cgi/wiki?CrossingChasms). You might also want to check
the Cetus Links web site (http://www.cetus-links.org/) to see if there
are any other papers and patterns that might be useful.
>From personal experience, the best approach that I have seen that allows
you to maintain extensibilty and manage dependencies is to use a
combination of proxies and query classes.
The proxies would wrap your domain classes and store information like
object IDs (primary keys used in the table where the "object" is stored)
and other persistence information that could complicate your domain
classes. You really want to strive for a design where the domain classes
are clean and are not polluted with persistence information. That just
makes dependicies really hard to manage.
The query classes know how to store and retrieve classes from the
database using JDBC or whatever database interface you have. They have
knowledge about how the database structure is laid out and encapsulate
it so no other objects need to know how the database is structured (or
that there is a relational database at all).
There are a few problems with this design such as dual ladders of
inheritence from the proxies and domain classes but it is the cleanest
design I have seen so far and the easiest to implement and still be
object-oriented.
Chris
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
