MEF与任何IoC

Question

看看微软的托管扩展框架(MEF)和各种IoC容器(如Unity)，我看不出什么时候应该使用一种类型的解决方案而不是另一种。更具体地说，似乎MEF处理大多数IoC类型模式，而像Unity这样的IoC容器就不是那么必要了。

理想情况下，我希望看到一个很好的用例，其中将使用IoC容器来代替或补充MEF。

Answer 1

归根结底，主要区别在于IoC容器通常最适用于静态依赖项(在编译时已知)，而MEF容器通常最适用于动态依赖项(仅在运行时已知)。

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

这样想:如果您正在开发整个应用程序，那么IoC容器可能是最好的。如果您正在编写可扩展性的代码，以便第三方开发人员扩展您的系统，那么MEF可能是最好的选择。

此外，@Pavel Nikolov的答案中的文章提供了一些很好的方向(它是由MEF的项目经理Glenn Block撰写的)。

Answer 2

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

MEF很擅长让你做到这一点。通常，IOC旨在确保您可以在未来的某个时候将基于ORMProduct1的IUserRepository替换为ORMProduct2。但是，大多数IOC解决方案都假设在给定时间只有一个IUserRepository生效。

但是，如果您需要根据给定页面请求的输入数据进行选择，则IOC容器通常会不知所措。

例如，我们通过MEF插件对我已经开发了一段时间的一个大型web应用程序进行权限检查和验证。使用MEF，我们可以查看记录的CreatedOn日期，并继续挖掘创建记录时实际生效的验证插件，通过该插件和当前有效的验证器运行记录，并比较记录的有效性。

这种能力还可以让我们定义插件的失效覆盖。我正在开发的应用程序实际上是为30+实现部署的相同代码库。因此，我们通常会通过询问以下内容来查找插件：

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

这让我们可以捆绑一组默认插件，但前提是特定的实现不会用客户特定的规则覆盖它。

IOC是一项伟大的技术，但实际上似乎更多的是为了简化对接口的编码，而不是具体的实现。然而，在IOC中，交换这些实现更像是一种项目转移事件。在MEF中，您可以利用接口和具体实现的灵活性，并在许多可用选项之间做出运行时决策。

Answer 3

我为我的离题道歉。我只是想说，有两个缺陷使得MEF变得不必要的复杂：

• 它是基于属性的，这并不能帮助你弄清楚为什么事情是这样的。没有办法了解框架内部的细节，以了解那里到底发生了什么。没有办法获得跟踪日志或挂钩到解决机制，并手动处理未解决的情况
• 没有任何故障排除机制来找出某些部件被拒绝的原因。尽管它指出了一个失败的部分，但它并没有告诉你为什么那个部分失败了。

所以我对它非常失望。我花了太多的时间与风车斗争，试图引导一些类，而不是解决真正的问题。我确信，当您完全控制VS调试器中的创建内容、创建时间和跟踪任何内容时，没有什么比老式依赖项注入技术更好的了。我希望提倡MEF的人能提出一堆很好的理由来解释为什么我会选择MEF而不是普通的DI。