gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] business


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] business
Date: Fri, 30 May 2003 16:22:35 +0200
User-agent: Mutt/1.3.22.1i

>>> business object layer: can reside on the client, or the server, or in
>>> between
>> Stateful or stateless ?
> I actually had persistent connections in mind, which would imply statefulness 
This is not what I mean. I am referring to whether a (possibly remote)
business object is expected to associate a particular client
with a particular data state. Example:

When adding an allergy entry I need a few pieces of information
to meaningfully make a consistent entry in the clinical record.
If the business object is stateful I can send it the pieces one
by one and later send a commit signal upon which the bOb
verifies the completeness and commits to the persistence
mechanism. If the bOb is stateless I have to send it all the
pieces at once and thus send an implicit commit signal. The
latter approach means the client needs to understand what a
"meaningful amount of clinical information" is under given
circumstances. This can be achieved by (smart) widgets
validating their input and transferring data when it validates
ok or else by teaching the frontend about the data being passed
on by the (dumb) widget. OR by coding all constraints in the
backend and propagating failures to the frontend which will be
desirable but often quite tedious.

IMHO, validation should be shared among the entities and bObs
be stateful.

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




reply via email to

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