I have a Hibernate entity object MyObject with several attributes and a service MyObjectService containing business logic dealing with MyObject. I also have a view model dealing with user input/output which uses MyOjectService. This service contains method updateMyObject(MyObject o) which is called by the view model when user changes some attributes, and it saves these changes into the database.
When some (not all) attributes of MyObject are updated, I need to notify an external system. I’m trying to figure out a best way of implementing this functionality. These are the solutions I came up with so far:
-
Method
MyObjectService.update(MyObject o)would get a second boolean parameter saying whether to send the notification to the external system. This is the simplest solution, but It’s probably not good to let the view model (which calls the method) decide whether to send the notification or not. I’d rather have this decision in the service. -
The view model would keep a copy of the original state of the object along with the modified state. Method
updatewould then have 2 arguments (before and after) and it would check whether the attributes which need to be notified of are changed. This would result in a pretty ugly condition likeif (before.attr1 != after.attr1 or before.attr2 != after.attr2 or ... )containing a large number of attributes which can grow in the future. -
Have a separate update method in
MyObjectServicefor each attribute ofMyObject. This way, each method would decide whether the notification has to be sent or not. This is probably the cleanest way, but I’d have to have a large number of update methods (1 for each attribute).
So each of these solutions has its disadvantages. Which one would you use? Or do you have a different idea how to do this? Is there some way I could use Hibernate to help me with this? (I tried to find out whether I could use Hibernate to find out which attributes are modified, but I didn’t find a satisfactory solution).
2
If I understand you correctly, you have two kinds of state-objects:
- The @Entity which is used in the persistence-context (Hibernate)
- The “viewmodel“, which deals with user input and as you describe: »which uses MyOjectService«
So your dataflow is from the user to the viewmodel and from the viewmodel to the Entity – we could neglect the persitence for your problem.
In this scenario is a third component – the MyOjectService involved and there is a strong coupling between the view-model and this service.
My suggestion is: implementing an observer-pattern.
Everytime, the viewmodel is changed, observers are notified:
1) One observer is responsible to call the MyOjectService on any change of the viewmodel
2) A second observer/model is responsible for managing the state to trigger the notification. It could consist only of three booleans (attribute1Set?,attribute2Set?, attribute3Set?) and if all three were set, an event is emitted to update the external service. After that, the attributes are resetted.
The workflow would look like the following:
Entity is fetched from db->Viewmodel filled->Trigger reset->Viewmodelchange leads to an Update in the database and eventually to changes in the Triggerobject->Triggerobject changes state and checks, whether it is necessary to update the external systems or not->Trigger fired=Trigger reset
You get the point;)
So you have clear responsibilities:
1) The @Entity is only for persistence
2) The Viewmodel is only for user-interaction
3) The “Trigger” is only for triggering the external sevice
The observer-pattern helps you decoupling and separating these responsibilities.
8