OperationScope sounds just like Germán's contextual lifestyle: http://blog.schuager.com/2010/11/contextual-lifestyle-reloaded.html(currently included in Castle.Windsor.Lifestyles: https://github.com/castleprojectcontrib/Castle.Windsor.Lifestyles ) See also http://stackoverflow.com/questions/5226659/castle-custome-lifestyle-per-resolve/5233300#5233300 I think the goal of the next version (I just skimmed over the discussion of Krzysztof / Hammett) is to simplify and also make this more powerful by decoupling scoping from lifestyles.
-- Mauricio On Sun, Mar 13, 2011 at 1:38 PM, Neil Barnwell <[email protected]>wrote: > I wanted to mention how I've approached non-web lifestyles recently in > desktop and windows service apps, without using the singleton or transient > lifestyles. I hope this is of interest; it's just far enough removed from > the notes on the Wawel scratchpad that I didn't want to pollute them, but > thought it might be useful in terms of the reuse vs. lifestyle problem. > > I love the idea of a component resolved from the container acting as the > context in which some other components are scoped for re-use, though the > issue here is how to approach the *lifestyle*, i.e. how that root > component might be released and therefore the components using it as a > scope. > > How I've approached a similar issue, is to create what I called an * > OperationScopeLifestyleManager*. This, as the name suggests, is a custom > lifestyle that I apply to certain components. The context used by this > lifestyle is a threadstatic-enabled *OperationScope* class that I wrote > (similar to *System.Transctions.TransactionScope* in concept). The idea is > to be able to write code like this: > > using (new OperationScope()) > { > // Do something that will ask the container for objects (e.g. ask for a > Form that will require an NH ISession). > MethodThatCallsContainerResolve(); > } // Each component resolved during this scope will be released by the > OperationScopeLifestyleManager > > I had considered offering this code as an additional out-of-the-box > lifestyle, but my main concern is that you could end up with * > OperationScope* usage in layers in one's app where that's not desirable. > It's not so bad in our case because we have a set of common assemblies I can > put it in, but if Windsor had it's own *OperationScope* we'd end up with a > lot of direct coupling to Windsor. > > It strikes me that the root component returned from the container in Wawel > that acts as the scope for the child components, is doing a similar job to > my *OperationScope*, but solves my problem of tight coupling to Windsor > assemblies. However, it's chicken-and-egg for implicit-scoping scenarios. > > I'm not sure this helps, but feedback would be much appreciated. :) > > Neil. > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Users" 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/castle-project-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Castle Project Users" 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/castle-project-users?hl=en.
