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 .
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, Collection )
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.
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 .
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, Collection )
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.