Re: [Gnumed-devel] proposal for dbapi base class

[Karsten Hilbert]

> class dbapi:
The naming is perhaps a bit unfortunate.

What is this to wrap ? 1:1 onto tables ? In which case
it could be named "dbtable".

IMHO it'd be useful to use the proposed class to represent a
table and build the business objects on top of that.

If we want to directly deal with tables in the business
objects (which is fine with me, too) I wouldn't write the
methods as generic as they are now, eg:

>       def fetch(self, pkey):
>               """fetch the record as identified by the primary key pkey.
>               The record can then be accessed via class attributes"""
>               raise PureVirtualFunction

The conceptual idea of this method does loose a lot of
flexibility as Ian points out.

I have so far found good success in writing the business
objects, then factoring out technicalities to clean up the
separations and then refactoring to unify common DB access
code. Works well for me. The business side API doesn't change
much. I guess what I want to say is that once we have 3-4 real
business objects in place it should (has to me) appear natural
what should be factored out. If really necessary we can even
then rewrite the base object(s) based on what we have learned
about developer/caching needs, access/usage patterns etc.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346