dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

On Mon, Mar 15, 2010 at 7:47 AM, Viet Nguyen <phamquocviet@xxxxxxxxx> wrote:

>
> Hi,
>
> I have a problem while doing this patient module that I want to share with
> you.
>
> Current, I do all the business logic code on action class.
>
> For example : I save patient, then save attributes, identifiers and
> relationship of that patient, all of those actions are called from action
> class. By this way, transaction can not be applied.
>
> So I want to put those things to service class, or another layer, I'm not
> sure what is the best for current frame work.
>
> I may create a method createPatient (.. ) in service class, and pass all
> needed parameters that I got from action class.
>
> This method may throw a custom exception, or return a boolean value, to let
> the action class know whether the create patient action is successful or not
> .
>
> So.. should I do this ? or keep current approach ?
>
> Please give some advices.
>
>
Hi Viet,

I had a look at addPatientAction and I can see you are mostly assembling
input params from the form, creating objects and saving those using the
service api. This kind of activity is the responsibility of the presentation
layer, so I don't think too much of that could be moved to the service
layer.

Regarding identifiers I see that Patient has an association to a collection
of Identifiers. This can be defined as a "cascading" association in
hibernate. Then you can populate your Patient object with those identifiers
and then there is no need to persist them manully first.

What might be feasible is to create a service method that takes the rest of
the assembled objects, something like

addPatient( Patient, Collection<AttributeValue>,
Collection<RelationShipType> )

With this you can take care of all of the saving in a transactional service
method.

Another comment, I see you update the patient multiple times in the action
class. Thats considered bad practice, hopefully I won't be necessary if we
refactor a bit. And its not really necessary since we use the
open-session-in-view spring interceptor as it will be dirty-checked
automatically by hibernate as you perform saving of the other objects.


Lars