MEF OSGi 是不是适用于 .NET？

Posted 2023-02-22

【中文标题】MEF OSGi 是不是适用于 .NET？

【英文标题】：Is MEF OSGi for .NET?MEF OSGi 是否适用于 .NET？

【发布时间】：2010-10-17 02:37:01

【问题描述】：

我现在只是想了解一下Managed Extensibility Framework (MEF) 并深入研究一下。我有 Eclipse 背景，所以在我的大脑中，我目前有以下等式：

MEF =~ OSGi for .NET

根据我目前所听到的。我在正确的路线上吗？

【问题讨论】：

您接受了最不具代表性的答案。对 MEF 一无所知，我无法将两者进行比较，但我可以坚定地确认 IoC 对 OSGi 来说根本不是问题，因此它不能用作区分特征。顺便问一下，你最终为你的项目选择了什么？

【参考方案1】：

Scott Hanselman 在他与 Glenn Block 的podcast 148 中帮助强调了有关 MEF 的细节。

与 OSGi 相比，MEF 建立在“控制反转”之上，OSGi 不是：它 (OSGi) 将通过基于生命周期层的不同机制发现新的捆绑包。

MEF 专注于应用程序的可扩展性。它使用 DI 作为组合不同扩展的策略，但它本身并不是一个通用的 DI 容器。

由于最后一点可能令人困惑，播客的transcripts 可以提供帮助：

我基本上定位它的方式，两者之间的区别在于，IoC 容器实际上是关于在不同环境中管理一组已知事物，就像我想要在我的磁盘环境中使用一个记录器，我想在我的测试环境中使用模拟记录器。

因此，MEF 实际上是关于管理一组未知事物，归结为，在 IoC 容器中，我倾向于执行基于约定或注册的特定注册机制，说这就是 logger 的意思，这就是这个意思，这就是那个意思。

MEF 使用代码和代码上的发现机制和注释，它们是 属性，无论系统中出现什么，这就是那里。

再一次，把它带到一个更高的层次，它是关于你使用 MEF 来真正管理一组 unknown 事物，你使用 IoC 容器来管理一组 已知 东西。

结论：（之一）主要区别在于发现原理（IoC 与生命周期）

【讨论】：

我认为播客的内容略有误读：“IoC 容器实际上是关于管理一组未知的事物”应该是“IoC 容器实际上是关于管理一组已知的事物”

您提到 MEF 是建立在“控制反转”之上的。 ayende.com/Blog/archive/2008/09/25/… 表示托管可扩展性框架不是 IoC 容器。

它是一个以“IoC”方式解决非常具体问题的框架，但它本身并不是“IoC”。来自 Glenn Block：所以我想说的是，如果您逐个查看场景，我们所做的一些事情与 IoC 容器所做的事情有重叠，我们如何做可能会有很大的不同，但它确实是关于最终目标我们构建它的目的。

你在说什么？？？ OSGi 可以向后和向前以十种不同的方式执行 IoC。

@drozzy 阅读下面彼得的回答：“有多个用于 OSGi 的 IoC 容器可用”。 OSGi 本身不做 IoC。它执行“代理”（服务发布和发现）和“DI”（依赖注入）：theserverside.com/feature/…

【参考方案2】：

请注意，OSGi 的设计目的是可以在其之上提供一个 IoC 容器作为一个模块，实际上，有多个用于 OSGi 的 IoC 容器以及其他机制：DS、iPOJO、Blueprint 等等。

【讨论】：

发现了一篇关于使用 OSGi 解决纯 IOC 方法中的缺陷的有趣文章：theserverside.com/feature/…。

【参考方案3】：

刚刚偶然发现这一点，但Prism 似乎是我见过的 .NET 中最接近 OSGi 的东西！查看他们在文档中的Modular Application Development 部分。

看看他们的模块依赖示例（几乎等同于捆绑！）：

<modules>
  <module assemblyFile="Modules/ModuleD.dll" moduleType="ModuleD.ModuleD, ModuleD" moduleName="ModuleD">
    <dependencies>
      <dependency moduleName="ModuleB"/>
    </dependencies>
</module>

微软的模式和实践团队似乎已经结束，相当于 OSGi 联盟。