拥有两个单独的 MEF 插件容器是不好的做法吗？答案

【问题标题】：Is it bad practice to have two separate MEF plugin containers?拥有两个单独的 MEF 插件容器是不好的做法吗？
【发布时间】：2012-06-16 01:22:20
【问题描述】：

假设我有一个类（不是静态类）A，它在某种程度上使用了插件。我使用 MEF 来管理这些插件，并为我的用户添加方法来添加部件目录。用法示例：

var myA = new A();
myA.LoadPlugins(new DirectoryCatalog("path/to/plugins"));
myA.DoStuffWithPlugins();

在与A 相同的命名空间中是类B。 B 也使用 MEF 来管理插件，并且有自己的 CompositionContainer。如果用户想要与B 的插件交互，她必须使用B 的插件管理方法。

B 的用法与上面的 A 一样。

我的问题是，这很糟糕吗？我是否应该关心在我的命名空间中有两个单独的位置来加载插件？如果不好，有什么替代方案？

【问题讨论】：

【解决方案1】：

我的问题是，这很糟糕吗？我是否应该关心在我的命名空间中有两个单独的位置来加载插件？如果不好，有什么替代方案？

不一定。没有理由不能在同一个应用程序中拥有两个完全独立的组合。

话虽如此，在大多数情况下，也没有真正的理由拥有多个作品。 MEF 将同时组合两组数据。在您的情况下，您可以使用相同的组合容器组合您的导入程序和您的报告，这将具有允许扩展您的系统的人只创建一个扩展您的应用程序的两个部分的单个程序集的优势。

这里一个潜在的小红旗是，它们是同一命名空间中的两种不同类型，但每种类型都有自己的插件系统。通常，具有完整插件系统的框架将足够复杂，以至于我会质疑它们是否属于同一个命名空间——尽管从“A”和“B”的类型名称来看，不可能知道这是否真的是不合适。

【讨论】：

是的，我可能对我的班级名称更具描述性:)。 A 类基本上是文件的导入器。它使用的插件是文件格式过滤器。 B 类从 A 类实例获取输出并生成报告。 B 类的插件是支持不同报告格式（HTML、txt、docx 等）的文件编写器
@SimpleCoder 而且，即便如此，我可能会有一个 Import 和一个 Reporting 命名空间，或者类似的东西......
有一个顶级命名空间，MyProject，它进一步分为Core和PluginFramework。导入和报告类包含在核心中。你认为我应该进一步拆分 Core 吗？
@SimpleCoder 我刚刚编辑了我的答案，以包含关于最后一条语句的更多详细信息。
让我们continue this discussion in chat

【解决方案2】：

我认为这没有任何问题。我会推荐class A 和class B 的基类来重用方法。

class A : BaseCompositionClass {
    //    implementations
}

class B : BaseCompositionClass {

    //    implementations
}

您可以使用单个CatalogExportProvider，然后查询该提供程序以获取匹配的导入和导出。然后，您可以使用单个 CompositionFactory，其中 classA 和 classB 请求组合。

【讨论】：