Pushing definitely is more performance efficient - you know exactly
when and where you push it and it's easy (happy-day-scenario) to
optimize. Partly the ease of optimization results from "difficulty of
making complex relations".
I would expect push to put more load on your servers due to
serializing to second level cache, and getting a page back from that
cache might also be more expensive. Of course, it depends where you
pull from. And then when you're within one request, you probably have
that data you'd push already in memory (e.g. Hibernate's session cache
if you use that), so it might not be more expensive in that sense
either. I do agree that pull models can lead to more complex
structures, but that also depends on what kind of models you use (e.g.
reflection based models actually can save code, but obviously using
lots of anonymous classes won't). :-)
Eelco
A third option, which from my POV is perhaps the most elegant, is to
roll your own page store that serializes the pages instantly after the
request. The serialization have special hooks to replace entites or
whatever that you would prefer to have as LDM with a placeholder that
just stores the type and id when serialized. When/if the page is later
deserialized you get the entity fresh from your object repository
(cache).
Why is this elegant? You get the programming model of push with the
benefits of pull without writing any code for model proxies. I have
communicated this idea before but nobody but me seems to prefer it,
I'm actually surprised :-)
// Daniel
jalbum.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
