Good to see you back
Thanks … came a week back with full of energy
In a sort of lose coupling of DHIS2 and CBHIS, I am planning the following
coding layout for the CBHIS.
A few thoughts and opinions. Feel free to disagree.
If you follow the approach above then try to implement some sort of
relationship between modules and packages. I think a module can
implement a number of packages, but packages should not be split
between modules. We have a lot of that at present which is confusing.
All of a package should be defined in one module.
Be clear what goes in the api and what goes in the service layer -
current rule of thumb seems to be that the api should be free-standing
(outside of “technology-choice” implementation lbraries). A
consequence being that the only dependency you would expect to see in
the api pom.xml would be probably junit (lets provide unit tests for
the api). If its about spring, hibernate, jdbc, jsf or what have you
it belongs in a different package in the service module.
The spring, hibernate, jdbc … stuff is something which we already have and it goes on under dhis-support module.
The api is to contain
o First_name – string
o Last_name – string
o Age – (integer) or shall we make it dateOfBirth? Because at somepoint we will register birth!
o Husband – person
o Wife – person
o Daughters – Set
o Sons – Set
o Address – house
o HouseNo – string
o GpsLocation – string
o Name – string
o Children – Set
o Parent – organisationUnit
o Name – string
o Freqency – periodType
o ProgramPhase – Set
o Name – string
o Header – ?XMLObject?
o Footer – ?XMLObject?
o Columns – ?XMLObject
o Owner – person (Health Extension Worker)
o Supervisor – person (Medical Officer)
o Date – date
o Activities – set
o Where – house
o When – date
o ForWhom – person
o What – houseHoldVisit
and some others which I couldn’t forsee the whole picture right now and list here. of course exceptions, logics (query), … will also be part of the api
The service is to contain the processing of the api’s - database persisting and any other business logic - like querying, activity plan generation, …
Finally the web part is to contain the presentation of the business logic.
Use the api to enforce business rules which are not enforced via the
database. We don’t do enough of that at present. The API sometimes
assumes that its users are always benign. Don’t do this. Expect the
worst and code for it. Part of the api should be a definition of
Is there a really good reason to have dhis-cbhis-api or should cbhis
be a package within dhis-api? I would lean towards having one dhis2
Not really … just easy plugability and lost coupling. Didn’t want to clutter the very strong sense of aggregate system - I just want to contain the objects of individual/patient/person and its related stuff.
On Mon, May 25, 2009 at 11:32 AM, Bob Jolliffe firstname.lastname@example.org wrote:
2009/5/25 Abyot Gizaw email@example.com:
dhis-support-xxxxx and dhis-i18n-xxxx and others will be shared from the
DHIS2 base framework.
Any comments or suggestions would be appreciated.
Mailing list: https://launchpad.net/~dhis2-devs
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp