RE: Common Object Management/Data Access Methods

> From: Dave Odom
> 
> Folks, I'd appreciate a thoughtful but rapid response:
> 
> Has anyone had experience with using "objects" to create a layer
around
> their databases, a Common Object Module(COM) as it were, that
supposedly
> makes access to databases easier for end-users and applications
> developers alike.   We have been approached by a vendor that says he
has
> built and can build around each of our divergent databases within
> different database machines, a "data access COM" made up of objects
> built on "object technology" similar to CORBA or Microsoft's
derivative,
> that will contain the necessary data access methods and logic able to
> mask having to know the underlying data structures of any database and
> any complex operations of any application front-ends now existing for
> applications against those databases.   Once built, this COM, he
claims,
>  would make it be much easier and faster for applications and queries
to
> be built.   I'm skeptical and hear "silver bullet" talk but I'm
willing
> to be convinced.
> 
> If anyone has had such an experience, how did the objects work, how
> were they built, how complex a task was that, what languages and data
> access methods are usually involved, what kinds of resources and
skills
> were involved, roughly, how long does each "object" take to create,
what
> are the support, performance, security, and management ramifications,
> what is the "good news, bad news" of which someone should be mindful?
> I did hear ODBC mentioned by him, which gave me shivers.

This is a huge question, but in general, yes it can be done.  The
reality of the situation, though, is that unless the layering is very
specific to your business, what you end up with is a bunch of pretty
stupid objects that really don't help you at all.

In a TRULY "database independent" design, you have THREE different
layers at the business object level (this is in addition to the view and
controller layers which run the application and display data to the
user).  The layers include a generic business object framework, a server
layer, and an implementation layer.

The business object layer provides common attributes that allow your
business objects to be treated homogeneously throughout the application.
Things like objects, types, lists, and so on are supported at this
level.

The server layer is where most of your logic resides, and its job is to
act as an Adapter (I'm using the specific OO term) between your
application and the database implementation.  It might, for example,
provide the logic whereby when an item master is added, an inventory
history record is also written.

The implementation layer translates generic data access to DB-specific
calls.  This addresses two different issues: it provides a consistent
interface to the server layer despite the database, and it allows you to
actually move data from one database to another without affecting your
application.  In either case, the implementation layer is the one that
deals with DB-specific issues.  For example, MySQL stores TIMESTAMP
information without the milliseconds.  This can cause grief for certain
applications.  The implementation layer would deal with this.

How long it takes to build an object depends on the amount of up-front
analysis done, because that affects the number of times you have to
rework the design because of new requirements.  Typically, a framework
takes a week or two to put together for prototyping, and with a properly
designed framework, adding extra objects is usually fairly simple.
Interestingly enough, the hardest bit is usually error handling.  You'll
take data from the screen and pass it to the server, and the server will
detect an error, but how does it let you know which field is in error?
And what do you do to handle that in the UI?

Anyway, this is as much as I can do off the cuff.  As I said, it's a big
subject, and while somebody may be able to quickly wrapper your
database, what you really need are hooks for incorporating all the
business rules down at the object level.  Without that, such a wrapper
is roughly equivalent to a simple remote database connection.

Joe