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

Question

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

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

与A相同的名称空间是类B。 B也使用MEF来管理插件，并拥有自己的CompositionContainer。如果用户想要与B的插件进行交互，则必须使用B的插件管理方法。

使用

B就像上面的A一样。

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

Answer 1

  

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

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

话虽如此，在大多数情况下，也没有真正的理由要有不止一种作文。 MEF将同时组合两组数据。在您的情况下，您可以使用相同的合成容器编写导入程序和报表，这样做的好处是可以允许扩展系统的人只创建一个扩展应用程序的两个部分的程序集。

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

Answer 2

我没有看到任何问题。我建议使用class A和class B的基类来重用方法。

class A : BaseCompositionClass {
    //    implementations
}

class B : BaseCompositionClass {

    //    implementations
}

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