Having difficulty refactoring a DB application

From: U-CDK_CHARLES\\Charles (_at_cdksystems.com)
Date: 10/07/04 

Date: Thu, 07 Oct 2004 16:40:38 GMT

List:

Apologies if this is a repeat.

My current project is a mess of close-coupling. I have sensible classes
that work for my "business model objects"

I have a sensible database definition that more or less works for the
application. We're still refining certain aspects of it, but it's more
or less set.

The problem as I see it is that I've SQL statements scattered
willy-nilly throughout the application.

Seems to me an object should be responsible for its own creation,
destruction and assignment.

I've come up with two possible solutions to this.

The first is to make the business objects aware of the associated stored
methods. The problem with this is that should the underlying methods
change, the classes will have to change to account for that.

The second is to put in an adapter class that knows how to access the
database.

Much of the difficulty for me is reconciling SQL's idea of a "record
set" with well-formed well-behaved objects. Some querys returns more
than one record, and others return records in different form, ill-formed
or partial objects. Some of this could be massaged, but I'm not certain
about proven methods for doing this.

Any other ideas about how to structure this aside from the two I've
stated?

Any relavant patterns, either in GoF or other references that apply to
this situation?

Thanx

Charles