Fredrik Liden <flide..ranslate.com> wrote:
> When creating a Web application.
>
> Can I fetch a dataObject to view it on a view page.
> Then modify the contents of this dataObject (without comminging) over
> serveral requests cycles and then finally commit the changes.
>
> In other words, can I store the dataObject in the session so I don't
> have to fetch again for every trip to the server during some updates, or
> do I have to fetch it every time a request is processed? How long can a
> dataObject stay active before I can no longer commit it? Do I need some
> buffer object like a VO object or JavaBean?
>
> Are there any guidelines for a good design?
I don't think there's any technical reasons why you couldn't do this.
However, I consider it a bad design to leave DataObjects in a modified, new,
or deleted state between requests.
There's never a guarantee that the user will submit the next page, nor is
there any guarantee that the user won't hit the back button a couple of
times and start working from that point, leaving your DataContext objects in
a strange state.
Let's assume you're using one DataContext per session. You start creating
a new Artist object due to a user request, but don't finish collecting all
of the information and thus don't save it. The user suddenly
back-navigates (or side-navigates) away from your Create Artist page to a
Delete Painting page. He deletes a painting and triggers commit. At
this point, the incomplete Artist object is still in your context and gets
committed as-is (or it causes a validation error and makes the deletion
fail).
I generally collect information required to make a change separately, then
move it all into the DataObject and commit it in one request/response cycle.
On the other hand, I have very few instances where data is collected in a
multistep process.
This archive was generated by hypermail 2.0.0 : Wed Feb 16 2005 - 10:05:18 EST