Is it OK? one could argue that if it works it's OK :) If your business model requires multiple UOWs per http request then yes it's a good model. If you are introducing S#arp because you are comfortable with it, and it makes sense, then yes it's OK. Do you need it, no.
If you do not need multiple UOWs within a single request, then I would recommend just using the request as the UOW boundaries. Fewer moving parts, less to maintain. On Nov 10, 6:40 am, Billy Stack <[email protected]> wrote: > I use Castle also. > I see myself doing this in a similar way except dealing with session > management at workflow level rather than begin request/end request > > e.g. the workflow method will have a PostSharp Aspect tag: > > [PersistenceUOW] > Workflow.DoWork(); > > Where PostSharp aspect will then "resolve factory, open session, start > transaction" at start of DoWork() method > and "commit/rollback transaction. dispose session" at end of DoWork() method. > > Also for me, the workflow will eventually call a repository (which is > injected via Castle) to do db tasks. > Its the repository that will get injected with the ISession (via > Castle), the same way via SessionFactory.GetCurrentSessionContext() > with Castle as you suggested > > From looking at my app architecture, its much more efficient to limit > the UOW to just the workflow and not a whole HTTP request. > > Does this sound ok? - Again cheers for the feedback > Billy --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
