Re: [Gnumed-devel] database abstraction

[Karsten Hilbert]

> It is in client/python-common/gmPgObject.py
Horst, I would suggest to keep those tests under test-area/.
We want to be able to work off a known, working state of
affairs in client/.

I see the following trend in what we are doing currently:

We move away from encapsulating business logic inside objects
towards encapsulating technicalities (such as how to actually
access a particular field in the database).

IMHO, when I write an object, say, cDrug. I want to be able to
say things like:

drug1 = cDrug("some data uniquely ID()ing a brand or generic drug")
drug2 = cDrug("some data uniquely ID()ing a brand or generic drug")

1)
if drug1.interacts(drug2):
    details = drug1.get_interaction_details(drug2)
    display_big_fat_warning(details)

2)
substitutes = drug1.get_substitutes(criterion="indication")

3)
if patient.pregnant() and drug1.has_preg_warning():
    display_big_fat_preg_warning(drug1)

or the like. IOW, have an API for business logic. This isn't
really concerned with underlying ways of how to actually
access the data itself. That may happend directly, cached in
multiple objects, cached in one large cache object,
you-name-it-i-dont-really-care.

I am happy to write business objects that deal with the
intricacies of the database. I am not happy having to be
concerned with this stuff while writing application level
code. If this results in a acceptable performance loss I am
OK with it (of course, acceptable is very subjective).

We need to clearly identify what layer we are currently
dealing with.

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