In my current project I do just that and it works fine. I must add that
it is a highly interactive application, so I work with long
conversations (managed hibernate sessions), where the transaction is
committed only after a number of request/response cycles after the user
clicks on 'save'. During the conversation my business objects are in
persistent state (never detached), and I wrap every business object in a
LDM, except I do not load from database, but from EhCache.
The only thing that I had to do, is move all validation, even simple
syntax checking, like field lengths, required fields etc., out of the
business objects, because I create a domain object with a default
(no-arg) constructor and add it to the Hibernate session. At that
moment, the object has invalid state (required fields have no data etc.)
So I have to trust on form validation and/or guide each object through a
validator before it is saved to the database or actually used in the
domain layer. Maintaining the objects validity combined with the
separation of layers is, I think, the only 'pitfall' I encountered that
I have not yet found a completely satisfactory answer for.
Hope this helps.
Stephen Swinsburg wrote:
Hi all,
I'm after your thoughts on the following method.
Suppose there is a wicket form with some fields that can map directly
to a simple Hibernate object, and hence a db table. Is it safe to
simply wrap this object in a CompoundPropertyModel and use it as the
backing model for the form?
Then in the onSubmit method, calling a method to get the object from
the form's model and saving it via Hibernate.
This does work fine, I'm just after any pitfalls that might happen
down the track. Very simple form here.
thanks.
S
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
