Great book. I'm learning much about Hibernate I never understood before. One area where I believe good hibernate patterns and techniques are missing is in the area of separating presentation and logic with regards to updating objects.

For example, the book mentions quite a bit the method of using detached objects as DTOs between presentation and logic. Yet the book seems to recomend a non logic based method of manipulating data. Creating, Deleting, and Querying all seem to be handled quite well by hibernate and the recomended patters but patterns for modifying data are covered very lightly. It almost seems like the implied approach to modify data is doing it in the presentation and not in the logic. If I want to put modify logic in a different tier then it would seem impossible to use the recomended DTO patterns.

Is it possible that we could get more examples in caveatemptor on how complicated modify and update logic and be handled when working in hibernate? I'm aware of http://hibernate.org/156.html but that method seems very difficult to manage and a cluge. Much more difficult then it seems the problem should be. If that is the best way to handle such a situation then I'd perhaps like to see an example of using that pattern in caveatemptor.

Regards,
Mike

I don't even know what "modify logic" is, so I can't write about it :)

Maybe that's the answer. :) Perhaps anytime you want to modify an object you just modify the object and any logic associated with it in the presentation layer. :)

But it would seem to me that just like you might want to perform some logic operations or validation on an object when it's persisted you would want to be able to do the same thing when it's modified. For example, when modifying a User object you would want to ensure that the user does not change certain fields....like the Account a user belongs to. I guess that would be an example of modify logic. You could do that in presentation if you want but if you're trying to separate and control business logic that wouldn't work. Does that make sence or do I need to come up with a better example? Or maybe I'm thinking of things all wrong.

Mike

This is called constraint checking or input validation and happens in the presentation layer and, of course, at the database level. It also helps to code defensive in your business layer (null checks, etc.).

Another example might be the case where a User's username is a business key and you don't want to mess up any of the Sets that user exists in by changing the username. Could require a fair amount of logic removing the user from all of the sets it is in and then putting the user back in all those sets.....That could be a case where you would have a changeUsername() method that is different from the updating the user but is that the optimal solution?

A sensible mix of control and business logic, as described with placeBid() and the DAO operations in chapter 8. Really, just because it looks difficult doesn't mean you can't split it up in those two categories.

Ok, thanks for your guidance. I think I'm slowly pulling my mind away from a Session Facade way of thinking which is what I think my problem is.

Mike