I am having a hard time devising a pattern for the modification of my persistent objects. I have a few objects that require some tedious validation prior to allowing the object to be updated. My desired pattern would be as follows:
1. UI get persistent object to be updated.
2. UI update modified fields.
3. UI pass object to Logic "modify" method to persist the update.
4. Logic compare new object with old to determine what has changed and perform complex validation accordingly or throw error if a field was modified that wasn't supposed to be.
5. Logic store new object.
Hibernate doesn't seem to want to function in this way. These are the problems I'm having.
1. If the UI grabs a persistent object and modifies fields then the fields are already part of the persistent object unless the transaction is rolled back. Seems to be no good way to safely obtain a detached version of the object and modify that before passing it onto the logic layer.
2. Because the modified persistent object is the current object to the local session there is no way to determine what fields have changed to compare with old object.
I'm familiar with the "Interceptor" but this Interface doesn't seem to do what I want it a clean way considering it is applied to a session and not to a persistent class. An Interceptor based approach would seem like a messy solution but maybe the way I'm thinking of using it is incorrect?
Anyway, I'm thinking there should be a good solution to this problem which probably involves changing my desired pattern above but I'm having trouble finding a pattern to replace the one above. Does anyone have any advice, pointers, or links to help me out?
Regards,
Mike
|