Re: [Gnumed-devel] database abstraction

[Hilmar Berger]

On Wed, 23 Oct 2002, Karsten Hilbert wrote:

> 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")
> ... snip...
> 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.

This functionality will be encapsulated in a different object (codename
DrugView) that I'm writing right now. It will provide an even simpler
interface to access drugs and won't depend anymore on the internals of
backend objects. The underlying backend API should than be replaceable by
whatever we want. In this respect DrugObject is just a quick hack to have
an easy to configure backend abstraction layer (although some of its
features I would like to keep in further API's).

> 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).

I absolutely agree. IMHO having a simple and reliable API pays off almost
always (the exception being unacceptable perfomance losses). And I
strongly believe that we can have simple API's in gnumed, too, without
loosing to much in performance. IMHO a good API shouldn't bother the
developer with any intrinsics of the low level implementation - it should
just do what one expects without much knowledge of the backend details.

Hilmar