[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] simplified GUI <-> database interaction
From: |
Hilmar Berger |
Subject: |
Re: [Gnumed-devel] simplified GUI <-> database interaction |
Date: |
Sun, 13 Oct 2002 15:18:31 +0200 (CEST) |
On Sun, 13 Oct 2002, Horst Herb wrote:
> 2.) All these queries communicate almost always directly with the backend: my
> analysis found that caching data really only makes sense for demographic
> details of the cuurrent patient. The other execption are "patient
> independend" list objects like a post code selector, but that is taken care
> of the "OnDefault" option (which would not update this widget when a new
> patient record is opened)
> We completely do away with complex data mapping, data abstraction and
> intermediate caching layers otherwise. If we don't, I found that performance
> suffers instead of the intended improvement.
>
> Drawback is that query results have to be mapped manually for each result and
> widget - but that is not as bad as it sounds.
I'm sorry, but can't completely agree with that ideas. I believe that we
would loose a lot of the benefits of a high-level object oriented language
if we have to do all backend communication 'by hand'. Hiding
implementation features in hierarchies of objects has certainly a
perfomance cost but simplify coding a lot. If, however, the costs to
access two or three performance-optimised objects in between the GUI and
the backend has that high an assigned cost that performance will suffer a
lot I would rather suspect that Python is not the langugage of choice to
code a project like gnumed.
How high are the performance hits you have found ? What is the part of the
abstraction layers having the highest perfomance costs ?
Are you sure there is nothing we can do to keep at least a minimal
abstraction layer ?
Hilmar