使用 MEF 作为 IoC
阅读以下内容后： http://mikehadlow.blogspot .com/2008/09/management-extensibility-framework-why.html
我知道 MEF 有一些我在 IoC 中找不到的功能，并且 MEF 有一些 IoC 东西，可能没有那么先进其他一些 IoC 系统可以提供。
我需要 MEF 的东西。我还需要 IoC 框架吗？或者我可以使用 MEF 的框架吗？
亚瑟
After reading some stuff such as this: http://mikehadlow.blogspot.com/2008/09/managed-extensibility-framework-why.html
I understand that MEF has some featcures that I will not find in an IoC, and that MEF has some IoC stuff that is probaboly not as advanced as some other IoC systems can offer.
I need the MEF stuff. Do I also need an IoC framework or would I be fine with what MEF has?
Asher
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我在 SoapBox Core 中使用 MEF 来实现可扩展性和 IoC。 CodeProject 上还有一篇文章，名为 使用 MEF、WPF 和 MVVM 构建可扩展应用程序 描述它是如何工作的。
I am using MEF for both extensibility and IoC in SoapBox Core. There's also an article on CodeProject called Building an Extensible Application with MEF, WPF, and MVVM describing how it works.
在最近切换到 AutoFac 之前，我在 Web 应用程序中使用提供程序模型本质上是“IOC”。
基本上我的要求是我需要能够“销售”应用程序，因此需要抽象任何接口。通过使用提供者模型，事情往往会变得混乱。使用 IOC 容器（如果您已经使用了）更有意义，而且我仍然可以满足“转售”的要求，因为 IOC 容器可以“重新配置”以允许不同的实现。
我认为如果您想要一个干净的代码库，MEF 将是最好的解决方案，因为它有更多约定，因此基本上人们可以将组件放入文件夹中，而不更改任何配置来引发更改。这很好，但对于我的场景来说可能有点矫枉过正，在这种情况下，简单的配置覆盖就足够了。
在我的博客文章中阅读更多内容 - 希望该博客也能得到一些好的评论：http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html
I was using the Provider Model for essentially "IOC" in web application before switching to AutoFac recently.
Basically my requirement is that I need to be able to "on-sell" applications, so any interfaces need to be abstracted. By using the Provider Model things tend to get messy. Using an IOC container (if you are already) makes more sense, and I can still meet my requirements of "on-selling" because the IOC container can be "reconfigured" to allow different implementations.
I think MEF would be the best solution if you want a clean code base because it has more conventions, so essentially people could drop components in a folder and not change any configuration to instigate changes. This is nice but possibly overkill for my scenario where a simple config override is sufficient.
Read more on my blog post - hopefully the blog will get some good comments about it too: http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html
取决于您的要求/现有代码。
如果您有一个基于 IoC 容器构建的现有代码基础架构，您实际上可以将它们与 MEF 结合起来。最近我一直在构建一个 ASP.NET MVC+MEF 框架，一些读者一直在问如何将 Unity 与我构建的 MEF+MVC 框架集成。事实证明，这非常容易，这要归功于一个名为 Common Services Locator 的项目。
CSL 项目旨在提供服务位置的抽象，因此我可以获取 Unity 的 CSL 提供程序，将其与自定义 ExportProvider 连接起来，MEF 会自动开始组合我的 IoC 驱动部件。
这是 MEF ExportProvider 模型的好处之一，您可以轻松插入任何其他提供程序以开始从各种来源提取导出。
上周我在博客中介绍了 MEF+Unity 的组合（还有 MEF+Autofac 作为另一个例子） ，尽管我的示例是为 ASP.NET MVC 准备的，但该概念对于大多数其他实现来说是相同的。
如果您可以选择使用 MEF 构建新的东西，您可能会发现您不需要 IoC 容器，MEF 可以处理属性注入、构造函数注入、部件生命周期管理和类型解析。
如果您有任何疑问，请告诉我:)
Depends on your requirements/existing code.
If you have an existing code infrastructure built on an IoC container, you can in fact combine these with MEF. Recently I've been building an ASP.NET MVC+MEF framework, and a couple of my readers have been asking how to integrate Unity with the MEF+MVC framework I have built. This turned out to be really easy, thanks to a project called the Common Services Locator.
The CSL project is designed to provide an abstraction over service location, so I can grab a CSL provider for Unity, wire it up with a custom ExportProvider and MEF automatically starts composing my IoC-driven parts.
This is one of the benefits of MEFs ExportProvider model, you can easily plug in any additional providers to start pulling exports from a variety of sources.
Last week I blogged about combining MEF+Unity (and also MEF+Autofac as another exmaple), and although my examples are geared up for ASP.NET MVC, the concept is the same for most other implementations.
If you have the option of building something fresh using MEF, you'll probably find that you won't need an IoC container, MEF can handle property injection, constructor injection, part lifetime management, and type resolution.
Let me know if you have any questions :)
国际奥委会遵循一个目的。
如果您想在系统中安装某种插件，MEF 的设计尤其出色。
或您不相信能够正常运行的代码（不要忘记处理异常）。
但是，它也因此带来了开销。
如果你只是想做 IoC，因为它是可扩展和可测试软件的良好设计模式，那么我会推荐 AutoFac，因为它来自同一个人。或多或少:-)
，如果您需要这两种意图。
然后使用两者。正如 Matthew 指出的，您可以使用 CSL 来抽象两者。如果想要的话。
对于插件 -> IoC 的MEF
->一个简单的国际奥委会
An IoC follows a purpose.
MEF specially is good designed, if you want to have some sort of plugins in your system.
or code that you do not trust to run properly (dont forget to handle exceptions).
but, it comes therefore with a overhead.
if you just want to do IoC, as it is a good design pattern for extensible and testable software, then i would recommend AutoFac, as it is from the same guy. more or less :-)
and, if you need both intentions.
then use Both. as Matthew pointed out, you can use the CSL to abstract both. if wanted.
for plugins -> MEF
for your IoC -> an simple IoC
我们使用 MEF 作为 IoC 容器，它正在为我们工作。
话虽这么说，您应该看看 Glenn Block 的这篇博客文章，他列出了您可能遇到的缺点：我应该使用 MEF 来满足我的一般 IoC 需求吗？
We use MEF as an IoC container and it is working for us.
That being said, you should take a look at this blog post by Glenn Block where he lists the shortcomings you might encounter: Should I use MEF for my general IoC needs?