MEF =可能会遇到挫折感？
UPDATE
因为我试图在我的应用程序中使MEF工作，所以我遇到了更多的地方，我只是不明白为什么它不会在我期望的时候自动创建我的库。 我想这一切都回到了里德所说的关于需要MEF来创造一切的东西。 所以现在，我有一个XML阅读器类需要使用我的CandySettings，但即使它的ICandySettings属性具有[Import]属性，它也不会被导入。 首先我发现[导入]不适用于静力学，所以我改变了这一点。 但在那之后它仍然无效。 我认为这是因为我手动创建XML阅读器对象，而MEF要我做的是[导入] XML阅读器…这意味着我现在必须有一个接口。
这几乎就像使用IoC（或至少用于MEF），这是一个全有或全无的事情。 你不能随便随意使用它，因为最终你想要注入属性的类也需要由MEF创建。
如果我错了请纠正我！
原帖
嗯，这还不错。 :)但是在Reed指出MEF作为IoC的潜在替代品之后我确实有问题（到目前为止看起来确实很不错）。
请考虑以下模型： alt text http://bit.ly/9W0sHt
正如你所看到的，我有一个应用程序，这个应用程序使用插件（哎呀，错过了那个关联！）。 App和Plugins都需要使用CandySettings类型的对象，这可以在另一个程序集中找到。
我首先尝试在MEF中使用ComposeParts方法，但我能让它工作的唯一方法是在插件代码中执行类似的操作。
var container = new CompositionContainer(); container.ComposeParts(this, new CandySettings()); 但这没有任何意义，因为我为什么要在插件中创建CandySettings实例？ 它应该在App中。 但是如果我把它放在App代码中，那么即使我在插件中使用[Import]和在CandySettings中使用[Export]，插件也不会神奇地弄清楚如何获得ICandySettings。 编辑 （可能是因为我应该从应用程序调用ComposeParts（）然后传递它的插件？）
我这样做的方法是使用MEF的DirectoryCatalog ，因为这允许插件在构造时扫描当前文件夹中的所有程序集并自动导入用[Import]属性标记的所有内容。 所以它看起来像这样，并且可能在每个插件中：
var catalog = new DirectoryCatalog("."); var container = new CompositionContainer(catalog); container.ComposeParts(this);
这完全有效，但我不禁认为这不是MEF的用途吗？
这里的“技巧”是你想让MEF为你创建你的插件。
你这样做的方法是让你的应用程序自己编写，并指定插件类型：
class PluginRepository { [ImportMany(typeof(IPlugin))] IEnumerable Plugins { get; set; } }
如果你这样做，并让MEF Compose你的“存储库”类， MEF将构造对象。 然后它会自动组合它们构建它们，因此ICandySettings将在没有任何干预的情况下编写。
如果MEF没有为您构建对象，则只需手动“组合”对象。