MEF 缺少什么才能与 IoC 容器相媲美?

发布于 2024-11-15 19:07:07 字数 1664 浏览 2 评论 0原文

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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

情愿 2024-11-22 19:07:07

MEF 缺少什么才能与 IoC 容器相媲美?

一种轻松诊断组合中问题的方法。

例如,如果你有一个依赖链 A -> B-> C-> D,而D缺失,则根据稳定合成 MEF 将简单地将 A、B 和 C 标记为不可用,并尝试在没有这些部分的情况下进行合成。您的错误消息将抱怨 A,而不是 D。

要诊断问题,您必须以某种方式转储组合诊断(例如使用 mefx) 并煞费苦心地沿着依赖路径向下,直到找到实际的问题。这虽然很痛苦,但还是有效的,直到引入循环依赖……

常规的 IoC 容器不存在这个问题。它只会告诉你“嘿,你已经注册了 C 以在组合中使用,但我似乎找不到它的依赖项 D”。

另请参阅我关于此的博客文章话题。

What is missing in MEF to be on par with IoC containers?

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.

‖放下 2024-11-22 19:07:07

正如所讨论的,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:

  • Optionally disabling rejection for easier diagnosis of errors in a system where you don't want anything to be rejected
  • Convention model support that lets you register types to be exported and imported instead of adding export and import attributes on the types themselves.
  • Open generic support, so you can export an open generic and import a closed version.
  • Better support for scoped/heirarchical containers, which may help with lifetime management.

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.

鹿童谣 2024-11-22 19:07:07

我不知道 MEF 的最新功能,但我能说的是 MEF 是一个解决应用程序可扩展性问题的框架。重点是为标准软件启用插件方案。它与“适当的”IoC 容器有很多共同特征,因此它将来可能会成为成熟的 IoC 容器。

Mef 的构建目的与 IoC 容器不同。其目的是提供一个
用于为标准应用程序启用插件功能的通用框架。从
从标准应用程序的角度来看,加载项本质上是未知组件

当我们使用 IoC 容器作为构建应用程序的工具时,我们知道
组成应用程序的组件。

IoC 容器的目标是服务的解耦组合,这很好,但当 MEF 的目标是组件的可发现性时,开发人员应该在配置容器时了解他希望组合的组件。您唯一应该了解的是您想要使用的抽象。

MEF 与 IoC 容器有很多相似之处,有时很难说我们应该如何考虑它。

我认为 MEF 的主要缺点是:

  • 与 IoC 相比,生命周期管理较差,
  • 缺乏拦截,

这是谈论 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 :

  • poor lifetime managment compared to IoC
  • lack of interception

Which are the main points when talking about IoC containers.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文