MEF 缺少什么才能与 IoC 容器相媲美?
MEF 是 不是 IoC 容器。但看起来它几乎是一个IoC容器。看来我可以轻松地使 MEF 表现得像一个 IoC 容器(请参见下面的示例),并且没有太多遗漏使 MEF 成为一个完整的 IoC 容器。
MEF 中缺少哪些 StrucureMap、Unity 等必须达到的实际功能?
您认为此功能请求有意义吗?
using System;
using System.Collections.Generic;
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
using System.ComponentModel.Composition.Primitives;
using System.Linq;
...
private CompositionContainer container;
public void Configure()
{
container = CompositionHost.Initialize(
new AggregateCatalog(
AssemblySource.Instance.Select(
x => new AssemblyCatalog(x)).OfType<ComposablePartCatalog>()));
var batch = new CompositionBatch();
batch.AddExportedValue<IWindowManager>(new WindowManager());
batch.AddExportedValue<IEventAggregator>(new EventAggregator());
batch.AddExportedValue(container);
container.Compose(batch);
}
MEF is not an IoC container. But it seems that it is almost an IoC container. It seems that I can easily make MEF behave like an IoC container (see example below) and there is not much missing to make MEF a full blown IoC container.
What are the actual features that are missing in MEF that StrucureMap, Unity, etc. have to get on par?
Would you think, this feaure request makes sense?
using System;
using System.Collections.Generic;
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
using System.ComponentModel.Composition.Primitives;
using System.Linq;
...
private CompositionContainer container;
public void Configure()
{
container = CompositionHost.Initialize(
new AggregateCatalog(
AssemblySource.Instance.Select(
x => new AssemblyCatalog(x)).OfType<ComposablePartCatalog>()));
var batch = new CompositionBatch();
batch.AddExportedValue<IWindowManager>(new WindowManager());
batch.AddExportedValue<IEventAggregator>(new EventAggregator());
batch.AddExportedValue(container);
container.Compose(batch);
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
一种轻松诊断组合中问题的方法。
例如,如果你有一个依赖链 A -> B-> C-> D,而D缺失,则根据稳定合成 MEF 将简单地将 A、B 和 C 标记为不可用,并尝试在没有这些部分的情况下进行合成。您的错误消息将抱怨 A,而不是 D。
要诊断问题,您必须以某种方式转储组合诊断(例如使用 mefx) 并煞费苦心地沿着依赖路径向下,直到找到实际的问题。这虽然很痛苦,但还是有效的,直到引入循环依赖……
常规的 IoC 容器不存在这个问题。它只会告诉你“嘿,你已经注册了 C 以在组合中使用,但我似乎找不到它的依赖项 D”。
另请参阅我关于此的博客文章话题。
A way to easily diagnose problems in a composition.
For example, if you have a dependency chain A -> B -> C -> D, and D is missing, then according to the principle of stable composition MEF will simply mark A, B and C as unavailable and will try to do the composition without those parts. Your error message is going to complain about A, not D.
To diagnose the problem, you'll have to dump the composition diagnostics somehow (e.g. with mefx) and painstakingly follow the dependency path downwards until you find the actual problem. Which is a pain but sort of works, until you introduce cyclic dependencies...
A regular IoC container does not have this problem. It will simply tell you "hey, you've registered C for use in the composition but I can't seem to find its dependency D".
See also my blog post on this topic.
正如所讨论的,MEF 并不是为了成为 IoC 容器而构建的。然而,它有很多相似之处。如果 MEF 提供的功能足以满足您的 IoC 容器需求,那么您可以继续将其用作 IoC 容器。
虽然 MEF 可能永远无法满足每个人的 IoC 容器需求,但在下一个版本中,我们正在进行更改,我认为这将使其值得更多人使用它作为 IoC 容器。以下是其中的一些:
托马斯提到拦截是一个重要特征。我们目前没有计划提供对此开箱即用的支持。我相信 MefContrib 确实以 InterceptingCatalog 的形式对此提供了一些支持。
As discussed, MEF wasn't built to be an IoC container. However, it has a lot of similarities. If the functionality MEF provides is enough for your IoC container needs, then you can go ahead and use it as an IoC container.
While MEF will probably never suit everyone's IoC container needs, in the next version we are making changes that I think will make it worth using as an IoC container for more people. Here are some of them:
Thomas mentions interception as an important feature. We don't currently have plans to include support for this out of the box. MefContrib does have some support for this in the form of an InterceptingCatalog, I believe.
我不知道 MEF 的最新功能,但我能说的是 MEF 是一个解决应用程序可扩展性问题的框架。重点是为标准软件启用插件方案。它与“适当的”IoC 容器有很多共同特征,因此它将来可能会成为成熟的 IoC 容器。
Mef 的构建目的与 IoC 容器不同。其目的是提供一个
用于为标准应用程序启用插件功能的通用框架。从
从标准应用程序的角度来看,加载项本质上是未知组件。
当我们使用 IoC 容器作为构建应用程序的工具时,我们知道
组成应用程序的组件。
IoC 容器的目标是服务的解耦组合,这很好,但当 MEF 的目标是组件的可发现性时,开发人员应该在配置容器时了解他希望组合的组件。您唯一应该了解的是您想要使用的抽象。
MEF 与 IoC 容器有很多相似之处,有时很难说我们应该如何考虑它。
我认为 MEF 的主要缺点是:
这是谈论 IoC 容器时的要点。
I'm not aware of the lates features of MEF but what can I say is that MEF is a framework that addresses extensibility concerns for applications. The focus is on enabling add-in scenarios for standard software. It shares so many traits with ‘proper’ IoC Containers that it may become a full-fledged IoC Container in the future.
Mef was built for a different purpose then a IoC container. Its purpose is to provide a
common framework for enabling add-in functionality for standard applications. From the
perspective of a standard application, an add-in is essentially an unknown component.
When we use a IoC Container as a tool to compose an application, we know about the
components that make up the application.
IoC containers aims decoupled composition of services which is good but the developper should know about the components he wishes to compose at the time the conainer is configured when MEF aims the discoverability of components. The only thing you should know is about a abstraction you want to use.
MEF shares so many similarities with IoC Containers that sometimes it's hard to say how we should consider it.
I think that the main disaventage of MEF is :
Which are the main points when talking about IoC containers.