读了一些东西，如在此之后：http://mikehadlow.blogspot.com/2008/09/managed-extensibility-framework-why.html使用MEF作为一个IoC
据我了解，MEF有一些featcures，我不会在一个IoC发现，和MEF有一些国际奥委会的东西，是probaboly没有先进就像其他一些IoC系统可以提供的一样。
我需要的东西MEF。我是否还需要一个IoC框架，或者我会对MEF的工作状况感到满意吗？
阿舍尔
取决于您的要求/现有的代码。
如果你已经建立了一个IoC容器在现有代码的基础设施，可以在事实上与MEF结合这些。最近我一直在建立一个ASP.NET MVC + MEF框架，和一对夫妇我的读者们一直在问如何团结与MEF + MVC框架我所建的集成。事实证明这非常简单，这要归功于一个名为Common Services Locator的项目。
CSL项目旨在提供服务位置的抽象，因此我可以为Unity提供一个CSL提供程序，使用自定义的ExportProvider进行连接，MEF自动开始编写IoC驱动的部分。
这是MEF ExportProvider模型的好处之一，您可以轻松插入任何其他提供商以开始从各种来源提取出口。
上周I blogged about combining MEF+Unity（还有MEF + Autofac作为另一个例子），尽管我的例子是为ASP.NET MVC做准备的，但对于大多数其他实现来说，这个概念是相同的。
如果您有使用MEF构建新鲜事物的选项，您可能会发现不需要IoC容器，MEF可以处理属性注入，构造函数注入，部分生命周期管理和类型解析。
如果您有任何疑问，请告知我:)
IoC遵循一个目的。
MEF特别是好的设计，如果你想在系统中有某种插件。 或代码，您不信任正常运行（不要忘记来处理异常）。
，但是，它有开销，因此来。
如果你只是想做IoC，因为它是一个可扩展和可测试软件的好设计模式，那么我会推荐AutoFac，因为它来自同一个人。或多或少:-)
和，如果你需要两个意图。 然后使用Both。正如马修指出的那样，你可以使用CSL来抽象两者。如果想要。
的插件 - > MEF
为你的IoC - >一个简单的IoC
我们使用MEF作为IoC容器，它为我们工作。
话虽这么说，你应该在哪里，他列出的缺点来看看由Glenn座这篇博客文章，你可能会遇到：Should I use MEF for my general IoC needs?
MEF2（在.NET 4.5框架中）解决了该文章中概述的问题。 – 2013-04-03 23:09:11
我使用MEF两个可扩展性和国际奥委会SoapBox Core。还有一篇关于CodeProject的文章，名为Building an Extensible Application with MEF, WPF, and MVVM，它描述了它是如何工作的。
我最近在切换到AutoFac之前，在Web应用程序中基本上使用了提供者模型来实现“IOC”。
基本上我的要求是我需要能够“销售”应用程序，所以任何接口都需要被抽象化。通过使用提供者模型，事情往往会变得混乱。使用IOC容器（如果您已经是）更有意义，而且我仍然可以满足“畅销”的要求，因为IOC容器可以“重新配置”以允许不同的实现。
如果你想要一个干净的代码库，因为它有更多的约定，所以我认为MEF将是最好的解决方案，所以基本上人们可以将组件放在一个文件夹中，而不是改变任何配置来煽动改变。这很好，但对于我的情况可能矫枉过正，只需简单的配置覆盖就足够了。
了解更多关于我的博客文章 - 希望的博客将得到有关它的一些很好的意见太：http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html
请注明的答案，造福于社会和你的支持率。 – RyBolt 2010-10-06 15:12:35