Question

我对用MEF控制成分范围的方法感兴趣。

最明显的示例 - Web应用程序，您必须在每个请求中创建某些组件子集，并在请求完成时处理它们。但是，范围的一般实现也可能在其他环境中有用。

我正在看MEF2预览并尝试理解它，但由于某种原因没有看到完整的解决方案。

一方面，有这个MVC integration module，其中MEF非常适合为我处理请求范围，但是在MVC之外（在网络之外）这是不可用的，是它？

另一方面，在第一个预览相关的帖子“What's new in MEF2”中，我看到这个名为CompositionScopeDefinition的东西看起来像是范围的明确规范，但有了这个，我没有办法“关闭”范围。换句话说：MEF如何确定何时处理在范围内创建的组件？

在第三方面（是的:-)，使用MEF v1，我曾经通过创建嵌套的CompositionContainer来处理范围，但是这对自定义ExportProvider不起作用。

真正想看的是：

   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

如果我有这个东西，我可以轻松地在它上面构建MVC集成，但我也可以在其他环境中使用它。

那么，问题又一次：你用什么来处理那样的范围问题？或者你说MEF还不够成熟以供认真使用吗？

Answer 1

好问题 - 我们正在制作更多应该回答您关于CompositionScopeDefinition的问题的文档。精简版; CSD通过ExportFactory<T>使用，其中CreateExport()返回一个句柄，用于控制范围的生命周期。

但是，CSD旨在针对桌面应用场景进行优化;毫无疑问，MVC集成使用过滤目录和嵌套容器来控制生命周期。这仍然是网络和其他工作处理场景中“事务”类型生命周期的推荐方法。

通过这种方法，使用自定义ExportProvider了解您所遇到的问题会更好。

我们正在努力实现一个更强大的“定制”终身故事;让我们知道MEF 2在哪些方面不适合你的场景，特别是通过CodePlex讨论论坛，这是一个很好的帮助。

Answer 2

我发现此帖子正在搜索有关CSD的详细信息。我想使用MEF创建可扩展的WPF应用程序，该应用程序具有允许客户端在单个窗口内的屏幕后打开屏幕的屏幕导航。每个屏幕都可以访问先前屏幕设置的部件，并且还可以覆盖某些部件。例如，当用户打开ProcessView时，它应该有一个ProcessProvider部件，可以通过从ProcessView导航的屏幕导入，比如说ActivityView。 ActivityView应该可以访问ProcessProvider，因此它将具有操作的上下文。

另一个例子是根屏幕可能有一个ProcessListProvider，它默认返回数据库中的所有进程。想要打开ProcessListView的屏幕需要以某种方式使用自定义的ProcessListProvider覆盖根ProcessListProvider，这样ProcessListView仍然可以使用自定义进程列表提供程序。

我希望我能够传达我的要求。

伊多。

如何明确和精确地控制构图范围？

2 个答案: