On 06/19/2015 01:59 AM, wix wrote:
Urbani, Edmund wrote
I don't think I am the only one running into these kinds of issues, so I'd
like
to hear which patterns other developers apply or what they consider best
practices.
Would like to hear the same. I've attempted to work through this in the
most Wicket-way I know how.
The approach so far is a kind of LoadableDetachableModel that tries to be
smart about the persistent state of the underlying entity/object. A
persistence provider (entitymanager or such) would be injected into the
model or requested by the model, and a flag or flags used to track the state
of the underlying entity - is the entity currently managed? is the entity to
be retained (that is, not automatically detached)? is the entity currently
attached?
So at the start of a wizard, the model is given a new entity and told that
it is un-managed and retained. As the model is passed to the next page or to
a previous page, the entity is serialized (not detached) and treated as
though it doesn't belong to a persistence context. At the end of the wizard
the model is told to persist the entity at which time it becomes managed but
not retained (so it detaches, and would be re-attached via persistence id
lookup when the model is next deserialized/loaded).
A wizard or other set of pages working with an existing entity that was
selected from persistence just tells the model that it is managed and
retained. Then the model still doesn't "detach" in the sense of setting the
underlying entity to null, but it does "detach" from the JPA context and is
safely(?) serialized. Thereby changes made in wizard pages ride along to the
end as in the new entity case above, and aren't merged til whatever final
page/part logic says so. Cancelling out in the middle is simple since no
changed would have been persisted.
It works for any generic entity in my projects so far, however my use case
right now isn't complicated by multi-entity editing; only one entity (one
model's underlying object) is being modified by a single form submission in
the open-session-in-view cycle.
If there are other drawbacks to this approach or a better way (a more
Wicket-way)...
Detaching from Hibernate / JPA session as you describe is another way to handle
this. Makes me worry about concurrent modifications which might be committed in
between detaching from / re-attaching to the persistence layer though.
Also, I have considered separating the presentation layer (Wicket) from the
managed database objects entirely and handle every interaction with the database
through a service layer which maps database objects to/from a different set of
classes tailored specifically for the UI and its various use cases. That would
be the "cleanest" approach I can think of, and also the most expensive one to
implement.
However, currently I am trying to hook into the serialization process to
untangle my partially persistent object graph as described in this article:
http://techblog.molindo.at/2009/03/detaching-and-attaching-persistent-objects-on-serialization.html
This seems to be working so far (pending some thorough testing) even though it
causes some weird exceptions in unit tests (javassist.CannotCompileException),
which I have yet to fix.
--
Mit freundlichen Grüßen
Edmund Urbani
Liland IT Team
Email: edmund.urb...@lilandit.com <mailto:edmund.urb...@lilandit.com>
Liland IT GmbH ...does IT better
Tel: +43 463 220111
Fax: +43 463 220111-33
Tel(GER): +49 221 65028588
Find us at Facebook http://facebook.com/Lilandit
http://green-badges.com
http://iventcloud.com
http://Lilandit.com
<http://www.LilandIT.com> <http://www.LilandIT.com>
Copyright © 2015, Liland IT GmbH
Diese Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Email irrtuemlich erhalten
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht
gestattet.
This email may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this email in error)
please notify the sender immediately and destroy this email. Any unauthorised
copying, disclosure or distribution of the material in this email is strictly
forbidden.
