Java – Logic based on modified fields of a Hibernate entity

designhibernatejavaobject-oriented-design

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

Best Answer

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.

Related Solutions

Hibernate Sessions – Best Way to Manage Hibernate Sessions in a Struts-1 Application

I don't think struts 1 ships with an OpenSessionInView filter, but one way to manage sessions is opening sessions on a per-request basis, which are then accessed via the thread local pattern.

This will keep the session open until the request is done rendering, meaning you can use lazily instantiated collections in your views safely.

Spring ships with an opensessioninview filter, here is an article on how to use it, or, it's relatively straightforward to write your own as a standard servlet filter.

to write your own, you would write ServletFilter that implements Filter, and implement a doFilter method. it would look something like:

void doFilter(ServletRequest req,ServletResponse res,FilterChain chain) {
   Session session;
   try {
      session = // get my hibernate session here
      // do the request
      chain.doFilter(req, res);
   } catch (Whatever) {
   } finally {
     // close my session here
   }

you would need to register this filter in your web.xml, and apply it to the URLs that you need sessions with. This is not the most elegant solution in the world, but it does work just fine.

Spring and Hibernate – Best Practices for Creating Views

With ORM technologies there are many ways to approach this. I think either of the ways you suggest are adequate, but I'll add the performance concern angle.

If you have performance concerns, then I suggest you look at the SQL produced (show_sql) as well as the network traffic via the JDBC driver (use P6Spy or similar) in both versions and see what impact they have.

Best Answer

Related Solutions

Hibernate Sessions – Best Way to Manage Hibernate Sessions in a Struts-1 Application

Spring and Hibernate – Best Practices for Creating Views

Related Topic