RE: MIDRANGE-L Digest, Vol 3, Issue 1810

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: Joel Cochran
> 
> This is very similar to what I had in mind.  Imagine a database file,
> either in SQL Server, Oracle, or iSeries.  Naturally, I want to
> encapsulate DB access to the file in a class.

Take this one level higher, Joel.  Encapsulate the application access to
the object in the object class.  Have high-level functions like create,
read, getList at the object level.  Application errors occur here, such
as required fields and stuff like that.

Next, for each class create an implementation class that acts as an
adapter between the object and the database.  This is an abstract class
that has a bunch of abstract methods for the basic I/O functions.  The
object calls the implementation class when it actually wants to access
the database.

Finally, you write one implementation adapter for each type of database.
The implementation class can be written to use JDBC to access a
database, or it can use the RLA functions of JTOpen to access the
database directly (or it can call a server program, or even invoke a web
service).  It can also be smart enough to do referential integrity and
constraints if the underlying database does not directly support them.

This also allows you to do things like split your database among
multiple machines.  Your application classes have no idea where the data
actually resides.  You can even do this by rows: current data can be
stored locally, while older data is stored on a slower high-capacity
drive.  The implementation class can handle accessing data from either
device based on the age of the item.

If you're going to write a framework for database independent
persistence, you might want to take the time to make sure you're
independent not only of the database, but of the database access
technique.

Joe