Re: Best Practices for DataAccess Layer in VB6


"jamesfreddyc" <jamesfreddyc@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:4AA2B3B0-8F44-4D2A-A4D9-AFF0270E6196@xxxxxxxxxxxxxxxx
I am trying to conceptualize the best approach to handle data access
throughout my VB6 app. As it is now, I have been creating ClassModules
for
each specific ADO recordset, which is just fine but I end up with many
ClassMod's (took the "NamesData" example from MSDN and re-built this for
each
ADOrs I needed to access).

Anyway... Just wondering if there are other, perhaps better organized
ways
to structure the DataAccess process.

Your comments, insights, and ideas are greatly appreciated!

j

There are two ways to approach these kinds of design decisions. One from a
business case point of view, the other from an OO point of view. All lead to
the same result. But one thing will become quickly apparent - no one model
will be 'best' for all occasions.

While often considered an 'advanced' topic. I feel a general understanding
of the impedence mismatch between OO and Relational technologies in the
beginning make the why's and how's of suggested strategies easier to
swallow.
http://www.agiledata.org/essays/impedanceMismatch.html

Put simply - the architecture and building blocks (often erroneously
referred to as 'objects') of a data store seldom relates directly to the
business needs or objects in a well structured application.

Building an object based on a specific query is a step in the right
direction from, say, simply creating an object based on each table. But even
then can be rather wasteful - since what is a Recordset but an object that
contains a collection of objects?

I see a lot of reading in your future. <g>

-ralph




.