MEF与任何IoC

Question

看着微软的托管扩展性框架（MEF）和各种IoC容器（例如Unity），我无法看到何时使用一种类型的解决方案。更具体地说，MEF似乎处理大多数IoC类型模式，并且象Unity这样的IoC容器不是必需的。

理想情况下，我想看到的IoC容器将被用来代替，或除，MEF一个良好的使用情况。

Answer 1

当煮浓后，主要的区别是，IoC容器通常是具有静态依赖（在编译时已知的）最有用的，并且通常MEF与动态依赖性（仅在运行时已知的）最有用的。

因此，它们都是合成引擎，但每种模式的重点都不相同。因此设计决策变化很大，因为MEF围绕未知部件的发现进行了优化，而不是已知部件的注册。

想想这样：如果你正在开发你的整个应用程序，一个IoC容器可能是最好的。如果您正在编写可扩展性，那么第三方开发人员将扩展您的系统，但MEF可能是最好的。

此外，在@Pavel尼科洛夫的答案的文章提供了一些大的方向（它是由MEF的项目经理格伦块，写的）。

Answer 2

我同意MEF可以是完全有能力的IoC框架。实际上，我正在编写一个基于使用MEF的扩展性和IoC的应用程序。我将它的通用部分加入到了一个“框架”中，并将其作为自己的框架开放，称为SoapBox Core，以防人们想要了解它是如何工作的。

特别是，看看在Host是如何工作的，如果你想看到MEF在行动。

Answer 3

我一直在使用MEF了一段时间，因为当我们用它代替IOC产品的关键因素是，我们经常有一个给定的接口在特定的时间坐在我们的插件目录中的3-5实现。实际应该使用哪一种实现实际上只能在运行时才能决定。

MEF擅长让你做到这一点。通常情况下，IOC的目标是确保您可以在未来的某个时间换取基于ORM产品1的ORM产品2的IUserRepository作为一个典型例子。但是，大多数IOC解决方案都假定在给定时间只有一个IUserRepository有效。

但是，如果您需要根据给定页面请求的输入数据选择一个，IOC容器通常处于亏损状态。

举个例子，我们做我们的权限检查，并通过MEF插件我们的验证一个大的web应用程序我已经工作了一段时间。使用MEF，我们可以查看记录的CreatedOn日期和挖掘实际上在记录创建时实际有效的验证插件，并通过该插件和当前有效的验证程序运行记录BOTH，并比较记录的有效性时间。

这种功能还可以让我们定义插件的fallthrough覆盖。我正在使用的应用程序实际上是为30多种实现部署的相同代码库。因此，我们通常会通过询问以寻找插件：

1. 特定于当前站点和特定记录类型的接口实现。
2. 特定于当前网站的接口实现，但适用于任何种类的记录。
3. 适用于任何网站和任何记录的接口。

这让我们捆绑一系列默认插件，但只有当特定的实现没有用客户特定的规则覆盖它时。

国际奥委会是一项伟大的技术，但似乎真的更多的是关于使它容易的代码接口，而不是具体实现。然而，将这些实现交换出去更像是IOC项目转移的一种事件。在MEF中，您可以灵活使用接口和具体实现，并使其成为许多可用选项之间的运行时决策。

Answer 4

我为脱离主题而道歉。我只想说，有2个缺陷，使MEF的不必要的复杂：

• 它是基于属性，它不会做任何好帮你弄清楚为什么事情的工作，因为他们做的。没有办法了解框架内部的细节，看看究竟发生了什么。没有办法获得跟踪日志或连接到解析机制并手动处理未解决的情况。

• 它没有任何故障排除机制来找出某些部件被拒绝的原因。尽管指出了一个失败的部分，但它不会告诉你为什么该部分失败。

所以我很失望吧。我花费了太多时间与风车试图引导一些班级而不是解决真正的问题。我确信，当你完全控制VS调试器中创建的内容，时间以及可以跟踪的任何内容时，没有比老派的依赖注入技术更好的了。我希望有人主张MEF提出了一系列很好的理由，为什么我会选择纯粹的DI。