In my example of Chinook Media Manager http://jfromaniello.blogspot.com/search/label/ChinookMM I've used the pattern described by Fabio "Conversation per Business Transaction" (you can google the posts of Fabio)
In my example two viewmodels were part of the same usecase, the session is one per use case (not per view), so I've an application service decorated with the unhaddins attributes for CpBT Aspect Oriented version. The source code is here: http://code.google.com/p/unhaddins/source/browse/#svn/trunk/Examples/uNHAddIns.Examples.WPF (try to go back to revision 839 - The "head" revision is little bit different) 2010/9/2 Kevin Anderson <[email protected]> > Thanks for the help with this. I am finding that implementing a "Session > per View Model" is problematic with a WPF application because there is quite > often a relationship between two view's (and thus view model's). > > For instance, we have a grid that display's a collection of records but > double clicking on a row brings up a detail view of the selected row. The > obvious solution was to pass the session from one view model to the other. > That was where things started to get really complicated. We have a button on > that view that uses information from that row and creates and an entirely > new entity (creates a job from a bid) and then we have another grid that > could be open displaying the collection of jobs. So do we use the session > from the bid's grid or the session from the job's grid? > > It seems to me that the "Session per view model" works fine as long as > there isn't any relationship's between views which in a WPF application is > unlikely. > > If I try to use separate sessions for each view model I get the exception: > "Illegal attempt to associate a collection with two open sessions" which may > be caused by my not closing the grid's session when I open the detail, but I > can't close it because it's possible that some lazy loading may still be > invoked based on the grid's filtering by the use. > > I am thinking that this should be a FAQ type question and that it can't be > only me but it seems most questions related to session management are > related to HTTP request/response scenario's which is not helpful at all. > > On 10-09-02 12:47 AM, Jeff Doolittle wrote: > >> @Oskar >> >> contradicted my own self at the very end! heh. >> >> On Aug 29, 9:17 pm, Oskar Berggren<[email protected]> wrote: >> >>> 2010/8/29 Jeff Doolittle<[email protected]>: >>> [...] >>> >>> factory. Sessions are cheap to create. The rule is "One Session per >>>> Application" (assuming you have one database you're working with) and >>>> many, many, many Sessions. >>>> >>> Make that "one session _factory_ per application...", which I'm sure >>> Jeff intended to write. :) >>> >>> /Oskar >>> >>> >>> >>> --Jeff >>>> On Aug 29, 4:22 pm, Kevin Anderson<[email protected]> wrote: >>>> >>>>> What are the implications of having one session (managed by IOC) that >>>>> is shared by the whole application? >>>>> We have a WPF, MVVM application that originally used one session for >>>>> each call to the repository, but found that we couldn't lazy load >>>>> anything because the session was gone. We moved the session of the view >>>>> model but found that in some instances a given object was being held in >>>>> two different sessions. We then tried moving the session all the way up >>>>> to the IOC and found that performance was fantastic. >>>>> I am concerned that there will be negative impacts from having one >>>>> session open for the lifetime of the application. >>>>> Any thoughts? >>>>> Thanks. >>>>> Kevin >>>>> >>>> -- >>>> 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]<nhusers%[email protected]> >>>> . >>>> For more options, visit this group athttp:// >>>> groups.google.com/group/nhusers?hl=en. >>>> >>> > -- > 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]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- 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.
