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 pattern.
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
