MEF OSGi 是否适用于 .NET？

Question

我只是想了解 托管扩展性框架 (MEF）目前正在深入研究。 我有 Eclipse 背景，所以我脑子里目前有这样的方程：

MEF =~ OSGi for .NET

基于我到目前为止所听到的。 我的做法正确吗？

Answer 1

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

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

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

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

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

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

MEF使用代码以及代码上的发现机制和注释，它们是
属性，系统中显示的内容就是该属性。

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

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

Answer 2

请注意，OSGi 的设计使得 IoC 容器可以作为模块在其之上提供，实际上，OSGi 有多个可用的 IoC 容器以及其他机制：DS、iPOJO、Blueprint 以及毫无疑问的其他机制。

Answer 3

只是偶然发现了这一点，但 Prism 似乎是最接近 OSGi 的东西在.NET中我见过！ 查看他们的模块化应用程序开发部分在文档中。

只需看看他们的模块依赖关系示例（几乎相当于捆绑包！）：

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

在 Microsoft，Patterns & 似乎已经结束了。 实践团队相当于 OSGi 联盟。