Re: Best Practices for DataAccess Layer in VB6

What say you?

Just chipping in here.
Been programming in ADO for nearly 8 years and C++ for longer but I tend to
think we have done things not as good as we could have.

What I think also applies to VB.

I tend to think we should have class objects that manage a table (or view)
If that means one of (or all of) Arrays, Stored Procedures, Recordsets,
Command objects, so be it. It should be such that it is efficient to load,
query, update etc your object.
If the object has to update a database then it should do whatever is
necessary, to efficiently update this. I dont think your object should
expose Recordsets, they should only be used to load/save etc and be internal
to the class. The details will vary depending on the nature of the table
and size.

With such a set of different objects that manage themselves, it becomes easy
to bolt an application together, calling the appropriate member functions of
the classes.

The approach we have at the moment is much more monolithic and I recognise
that we should not have done that. It means more copy-and-paste between
projects and more writing of similar versions of boilerplate code. But we
will get there.

Stephen Howe


.