Tobias, I also find it's really important when using Hibernate. Hibernate is a total dog unless all your fetches are Lazy (so you only load what you need). With any UI, you load your entity and display a certain amount, but based on user action, you might need lazy loaded dependencies - with a loadable detachable model, the main entity is always 'fresh' in the session and lazily loaded dependencies are always available. It means everything in your data can be specified to be lazy loaded. Your data model is clean, your UI is clean.
In other UIs frameworks, or when I've used Wicket without LDMs, I spend half my time dealing with Lazy Load Exceptions, or having to pre-load certain lazy loaded entities for certain screens, that may or may not ever be used. You end up changing your data model to fit your UI (ugh!) or having tons of duplicated, effectively redundant, UI specific service methods (ugh!). Cheers, Col. -----Original Message----- From: Chris Colman [mailto:[email protected]] Sent: Friday, 23 November 2012 12:53 AM To: [email protected] Subject: RE: How important is detaching models really ? I guess in more complex apps the UI elements end up with lots of references to model objects so detaching does save a lot of memory and it also makes transferring session data from one web server to another (if required) in a multi server environment, much more efficient. I have experienced the result of accidentally serializing an object graph with megabytes of data that didn't use detach - ouch! The other benefit of detaching is your model will expose updates to the UI (if a redisplay occurred) that were made in other ORM sessions (depending on your ORM). Keeping a non detached copy of the model object will typically be like caching it in it's current state for most ORMs - i.e. it can get stale >-----Original Message----- >From: tobi [mailto:[email protected]] >Sent: Thursday, 22 November 2012 9:10 PM >To: [email protected] >Subject: How important is detaching models really ? > >Hi guys, > > From my understanding & experiments with Wicket's built-in session >inspector , detaching models seems to just affect the size of the page >store (and of course cut-down the amount of I/O required for serializing >the object graph). The session size shown on my pages is a constantly >low value (<1k , we're storing nothing except the currently logged-in >user). > >So it *seems* not detaching models has no effect on the (long-term) >memory footprint of a Wicket application. > >According to >https://cwiki.apache.org/WICKET/working-with-wicket-models.html , not >detaching models should affect the session size but at least looking at >the inspector I can't see this. Is the wiki article still correct / the >inspector not telling the truth ? > >Thanks, >Tobias > >P.S. I'm using Wicket 1.5.8 btw > >--------------------------------------------------------------------- >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] EMAIL DISCLAIMER This email message and its attachments are confidential and may also contain copyright or privileged material. If you are not the intended recipient, you may not forward the email or disclose or use the information contained in it. If you have received this email message in error, please advise the sender immediately by replying to this email and delete the message and any associated attachments. Any views, opinions, conclusions, advice or statements expressed in this email message are those of the individual sender and should not be relied upon as the considered view, opinion, conclusions, advice or statement of this company except where the sender expressly, and with authority, states them to be the considered view, opinion, conclusions, advice or statement of this company. Every care is taken but we recommend that you scan any attachments for viruses. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
