[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] re: messy code

From: syan tan
Subject: [Gnumed-devel] re: messy code
Date: Sun, 30 Nov 2003 00:18:38 +1100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313

I had a look it , after a break learning something else for fun, and I agree, it does look a bit messy, especially when
the reasons for doing things aren't justified explicitly.

These were the structural ideas I was following:

Each unit of data has it's own CRUD business object ( create update delete , possibly find) : a coarse grained unit is ClinicalRecord, and a finer grained unit is PastHistory, Allergy, Medications etc... The finer grained unit was chosen , since it would tend to follow the table clin_root_item subclasses.

Each business object for a specific type, has an unvarying CRUD interface, but over time, the actual processing done may change. Separate parts that are going to change more quickly from the parts that
aren't going to change as much.
The core tables in gmclinical were regarded as a more slowly changing part, vs extra tables to store extra
field data specific to edit areas, which might change more quickly.
I started off here using the multiple implementations for one interface idea, as used in Decorator and Proxy patterns, and had a second class mimic the inteface of gmPastHistory. I was going to get the gmPastHistoryEditAreaFacade to forward calls to gmPastHistory, but then I came across the idea that updates should be all or none , with regards to one transaction, so I thought updating the extra fields for the editarea for the past history object was in the same transaction as updating clin_past_history. So then I separated create_past_history in gmPastHistory into a transaction managing part and a backend updating part, and called the latter _create_past_history. Then I got gmPastHistoryEditAreaFacade to have it's own _create_past_history, but also have a transaction managing part create_past_history, which called both it's own _create_past_history and the gmPastHistory's _create_past_history ( which is the backend updating for the core clin_history table).

That way, both core and peripheral updates were within one transaction,
with the subsequent tradeoff  that  the thing looks like
a mess , and no one can understand I tried to start of with the Decorator Pattern !

Well, mea culpa, and someone please step up to write the coding guidelines !! (e.g. You could say - NO PARTITIONING , keep all updates whether extraneous/temporary or not , within one update method
for one entity ).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]