If the long running workflow is simple enough I would build up a DTO across multiple requests. the final request would make all the db calls. If the workflow gets complex I would look into storing the domain object in session. this would probably require calls against the session to disconnect and merge while in web session (since the nh session will be closed between requests). There may also be patterns for storing the NH session in the web session for long running workflows. I cannot see how this would be a good/scalable solution though.
I have only required the first suggestion of building up a dto. I haven't had a need to store domain objects in session. On Jun 1, 12:17 pm, Guga Oliveira <[email protected]> wrote: > Hello all, > > We have learned a lot with you this week. > > I am curious about how the most of you work with the objects in a > complex web page that do more than one request to the server. > > How do you preffer to work, persisting objects in every request and > storing the ids in the viewstate or session, or work with the objects > in the asp.net session and only in the final request do the > persistence (commit or flush). > > Thanks a lot. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
