Mario Ivankovits wrote:
Hi!
To me, it makes sense to use Transfer Objects,
* How do you deal with versioning?
If you directly use the hibernate object and use lock() to reassociate
it you can use hibernates versioning check to see if another
user already changed this object too and can tell the user its change is
no longer valid.
Works only if you have not changed the data in between...
But update also cries if the data has been altered...
To enable versioning, you have to set a version field in your table,
I tried that approach with my last JSF project, it works like a charm...
The flow sort of was like this...
Version field.. let hibernate do the version checking
hibernate throws an exception... push the exception through the spring
layer, let a dedicated interceptor (a spring AOP construct would be
possible) deal with the error in a standardized way and push the error
message to the user interface layer...
That way you simply have a good error handling as long as you use a
BO/DAO approach with automated error message feedback.
The ideal case would be to weave that stuff via aspects directly over
the BOs/DAOs and dont code anything yourself in that area....
JSF enforces that pattern because you can set the error messages over
singleton/factory constructs, which are theoretically accessible from
any layer, and from any interceptor class. With Struts it was much
harder to do that, in the end I had to move the error interceptor doing
that stuff into a base supporting class which basically was woven around
the Struts Actions execute method. One of the areas, where I really
prefer JSF over Struts, at first it looked weird to have everything
accessible over a central Singleton/Factoriy but the deeper you dive
into such things, the more you see that those things make a lot of sense.
