cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Turner <>
Subject Re: DataContext scope in web apps
Date Mon, 27 Mar 2006 04:08:44 GMT

Malcolm Edgar wrote:
> I am finding that with the Cayenne web app design pattern where the 
> DataContext has session scope, it is easy to add objects to the 
> DataContext when building up an object graph for display. If these objects 
> aren't explicity committed by request it is easy to have them carried 
> forward in the session DataContext, and have them committed in a 
> subsequent but unrelated request.

In the past I have had problems where the user will fail validation on 
one screen, move to another, attempt a save, and then run into problems 
because objects from the old screen are still sitting in the datacontext.

I get around this these days by using different DataContexts for 
different flows. Each subsystem in my app is associated with a different 
'workflow' in the engine, and each workflow has its own DataContext. 
I've been very happy with this pattern. And if there are situations 
where one updating can have flow-on-effects to another, then I get that 
workflow to reset the affected workflows so that they'll be built up 
from scratch again if the user returns to those screens. As my app is a 
webapp this is acceptable usage - in fact I've been very happy with this 

One of the advantages of cayenne over EOF (at least in my experience) is 
that you can remove things from the graph after adding them, which makes 
it nice as a hacky object-graph-on-demand even for things that you'll 
never persist to the database. But I find that using multiple 
datacontexts I rarely need to remove things from the graph.

But I mention the pattern because one thing I've been considering doing 
in one particularly complicated workflow is to have an accumulator 
object graph that never actually gets committed, but when the user saves 
or changes something a new datacontext is derived from it. A bit 
expensive on memory and processing, but probably an easy way to achieve 
what would otherwise be quite a complicated algorithm. Maybe this is 
something you could consider.

   - C

View raw message