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:

  1. 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.

  2. The view model would keep a copy of the original state of the object along with the modified state. Method update would 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 like if (before.attr1 != after.attr1 or before.attr2 != after.attr2 or ... ) containing a large number of attributes which can grow in the future.

  3. Have a separate update method in MyObjectService for each attribute of MyObject. 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).

  • What is the source for updating the object? Where does the data come from? As far as I can see, you describe the @Entity and a Service, but say nowhere where the data is from. If it is somewhere deserialized from JSON, you could take the attributes set via JSON as a trigger for the update. – Thomas Junk Oct 7 '14 at 15:30
  • The data comes from and is saved back to a database. It's mentioned in the question along with the fact, that I'm using Hibernate, which also suggests the data being stored in a database. Source for updating the data is user input (handled by the view model). – Jardo Oct 7 '14 at 15:45

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.

  • Well in your answer you pretty much described my current state except for a few details: 1. the @Entity just holds the data, it is not responsible for the actual persisting (this is done by MyObjectService). 2. Viewmodel is only for user interaction like you said. 3. The "trigger" is MyObject service (it is responsible both for persisting the data and notifiing the external system). So our concepts are the same, I just need to figure out the best (cleanest) way of writting it in code. – Jardo Oct 8 '14 at 9:30
  • Or in other words: The question is HOW should the "trigger" decide whether to send the notification. – Jardo Oct 8 '14 at 9:38
  • Let me phrase it different: The @Entity is only relevant in the context of persistence. The viewmodel is only relevant in the context of user-interaction. And the "trigger" is only relevant in the context of calling an external webservice. Our concepts are the same, but not the mechanics: the view model does not do/call anything, it only holds data and reports changes, to which observers could react. How they react is up to the observers. You are able to bind several different observers for different purposes on one model. One for updating a DB, one independent for calling external services. – Thomas Junk Oct 8 '14 at 10:08
  • Everytime the viewmodel is updated, it emits an event telling its observers, what changed. The "trigger" listens to some of the changes and maintains its own state. Assume a stream of events: 1,2,3,4,5,6... The trigger listens for 1,3,5. And sequentially its own state changes to 1=true,3=true=5=true. After each change, it checks, whether it should send the "135 are set" event, which signals exactly that. After the 5 is reveived, the trigger sends "135 are set" and a listener to that could take actions (e.g. notify external systems). – Thomas Junk Oct 8 '14 at 10:11
  • What you're suggesting is replacing MyObjectService with observers, which doesn't really solve my problem. You say that every time something changes, the viewmodel should tell the observers what changed. And this question is about HOW to tell the observers what changed (doesn't really matter if it's an observer or a service). – Jardo Oct 8 '14 at 10:50

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.