CODEWITHSUNDEEP
c#.netmef
Fyodor Soikin
Fyodor Soikin

Reputation: 80915

How to explicitly and precisely control composition scoping?

I'm interested in ways to control composition scoping with MEF.

The most obvious example - web applications, where you have to create certain subset of components per request and dispose of them when the request is finished. However, a general implementation of scoping may be useful in other contexts as well.

I'm looking at MEF2 preview and trying to make sense of it, but don't see a complete solution for some reason.

On one hand, there is this MVC integration module, where MEF is nice enough to take care of request scope for me, but that is not very usable outside of MVC (and outside of web for that matter), is it?

On the other hand, in the first preview-related post "What's new in MEF2", I've seen this thing called CompositionScopeDefinition that looks like an explicit specification for scopes, but with that one, I don't see a way to "close" the scope. To put it in other words: how does MEF determine when to dispose of components that were created within a scope?

And on third hand (yep :-), with MEF v1, I used to deal with scoping by creating nested CompositionContainers, but that doesn't work very well with custom ExportProviders.

What would really like to see is something like:

   using( var scope = compositionContainer.OpenScope( /* some scope definition here */ ) )
   {
      var rootComponent = scope.GetExport<MyRootComponent>(); // The component graph gets composed at this point
      rootComponent.DoYourScopedThing();
   } // The component graph gets disposed at this point

If I had that thing, I could easily build MVC integration on top of it, but I could also use it in other contexts.

So, the question again: what do you use to deal with scoping problems like that? Or do you say MEF is not yet mature enough for serious use?

Upvotes: 2

Views: 695

Answers (2)

Ido Ran
Ido Ran

Reputation: 11414

I've found this post searching for details about CSD. I want to use MEF to create extensible WPF application which has screen navigation that allow the client to open screen after screen inside a single window. Each screen should have access to parts setup by previous screens and also have the ability to override some parts. For example, when the user open a ProcessView it should have a ProcessProvider part which may be imported by screen navigated from the ProcessView, let's say ActivityView. The ActivityView should have access to the ProcessProvider so it will have context on which to operate.

Another example is that the root screen may have a ProcessListProvider which by default return all processes in the database. A screen that want to open the ProcessListView will need to somehow override the root ProcessListProvider with a customized ProcessListProvider so the ProcessListView will still work but with the customized process list provider.

I hope I was able to communicate my requirements.

Ido.

Upvotes: 0

Nicholas Blumhardt
Nicholas Blumhardt

Reputation: 31887

Good question- we are working on more documentation that should answer your question about CompositionScopeDefinition. Short version; CSD is used via an ExportFactory<T>, where CreateExport() returns a handle that is used to control the lifetime of the scope.

However, CSD is intended and optimized for desktop application scenarios; as you have no doubt seen, the MVC integration uses filtered catalogs and nested containers to control lifetime. This is still the recommended approach for 'transactional'-type lifetime in web and other work-processing scenarios.

it would be good to know more about the problems you face using custom ExportProviders wih this approach.

A stronger 'custom' lifetime story is something we're very much working towards; letting us know about where MEF 2 falls short for your scenarios, especially via the CodePlex discussion forum, is a great help.

Upvotes: 3

Related Questions