Marco Rolappe wrote:
-----Ursprungliche Nachricht-----
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Auftrag
von Leszek Gawron
Gesendet: Mittwoch, 2. Juni 2004 14:21
An: [EMAIL PROTECTED]
Betreff: Re: AW: JXTG and caching
Marco Rolappe wrote:
If your business object takes an age to instantiate, and you can decide
whether or not to instantiate it based upon request parameters, then
wrap it in a lighter component that does (in pseudocode):
IMO that's what the controller would be supposed to do; just
like preparing
the bizData and 'sending' it to the flow context, it would determine the
caching info and send it to the flow context. then JXT would
use the bizdata
and accompanying cache info from the flow context. SoC IMO.
Imagine that you have a view that is constructed out of several
aggregates
(nested to be harder). Every aggregation part has it's own
validity so while
preparing data you would have to consider the exact view composition and
generate view for those parts which already expired. Not so much SoC IMO.
composite view would imply composite validity, so I don't see a problem.
still SoC IMO ;-)
see my example of heavy biz data preparation. Suppose every aggregation part
needs another part of bizData. If you make it simple and show cached view only
if all parts were still valid it would be hardly usable. If you make it
complex the controller needs to know which data to prepare so it has to know
view rendering details which breaks SoC IMO.
--
Leszek Gawron
