我正在寻找一个可与 Eclipse 插件框架相媲美的基于插件的应用程序框架,在我看来,它包括:
- 一个核心插件管理框架(Equinox / OSGI),它提供了声明扩展端点的能力,然后发现和加载为这些端点提供服务的插件。(这与依赖注入不同,但不可否认,差异是微妙的 - 配置高度分散,存在版本控制问题,可能涉及在线插件存储库,对我来说最重要的是,用户应该很容易添加插件,无需了解底层架构/配置文件)
- 多层插件,提供基本的工作台外壳,支持并发、命令、首选项表、菜单、工具栏、键绑定等。
这只是触及了 RCP 的表面,它本身旨在作为您的应用程序的基础,您可以通过编写/组装更多插件来构建它。
以下是我这两天从网上搜集到的……
据我所知,.NET 世界中没有任何东西可以远程接近 Eclipse RCP for Java 的健壮性和成熟度,但是有几个竞争者在 #1 或 #2 方面做得很好。
(我还要提一下,我还没有对 WinForms 和 WPF 做出最终决定,所以我也在尝试了解任何候选框架中的 UI 耦合程度。我也想知道平台耦合和源代码许可)
我必须说,开源的东西通常文档较少但更容易理解,而 MS 的东西通常有更多的文档但更难访问,所以对于许多 MS 技术,我想知道它们实际上做了什么,在实际意义上。
这些是我找到的库:
夏普发展
我看到的第一件事是 SharpDevelop,它以基本的方式同时执行 #1 和 #2(没有侮辱 SharpDevelop,这是令人钦佩的 - 我的意思是比 Eclipse RCP更基本)。然而,SharpDevelop 是一个应用程序而不是一个框架,并且存在基本的假设和限制(即在某种程度上与 WinForms 耦合)。尽管如此,还是有一些关于 CodeProject 的文章解释了如何将其用作应用程序的基础。
系统插件
System.Addins 似乎旨在提供一个强大的加载项加载框架,具有一些复杂的选项,用于加载具有不同信任级别的程序集,甚至运行进程外。它似乎主要是基于代码的,而且代码量很大,有许多程序集用于隔离版本控制问题。使用 Guidance Automation 生成大量代码。
到目前为止,我还没有找到很多 System.AddIns 文章来说明如何使用它来构建类似 Eclipse RCP 的东西,而且许多人似乎对它的复杂性感到不安。
单声道插件
Mono.Addins 似乎受到 System.Addins、SharpDevelop 和 MonoDevelop 的影响。它似乎提供了 System.Addins 的基础知识,插件加载选项不太复杂,但更简单,具有基于属性的注册、XML 清单和在线插件存储库的基础设施。
它有一个很好的常见问题解答和文档,以及一组相当健壮的示例,这些示例真正有助于描绘如何开发像 SharpDevelop 或 Eclipse 这样的架构。这些示例将 GTK 用于 UI,但框架本身并未与 GTK 耦合。所以它似乎很好地完成了#1(加载项加载),并为#2(工作台框架)指明了方向。看起来 Mono.Addins 是从 MonoDevelop 派生的,但我还没有真正研究过 MonoDevelop 是否提供了一个好的核心工作台框架。
托管可扩展性框架
这是目前每个人都在谈论的内容,并且它的作用正在慢慢变得清晰,但我仍然很模糊,即使在阅读了几篇关于 SO 的帖子之后。官方的说法是它“可以与 System.Addins 并存”。但是,它没有引用它,并且似乎重现了它的一些功能。因此,在我看来,它是 System.Addins 的更简单、更易于访问的替代方案。
它似乎更像 Mono.Addins,因为它提供了基于属性的连接。它提供了可以基于属性或基于目录的“目录”。它似乎没有提供任何 XML 或基于清单的连接。到目前为止,我还没有找到太多的文档,而且这些示例似乎有点“神奇”,更让人联想到基于属性的 DI,尽管澄清说 MEF 不是 DI 容器。
它的许可证刚刚开放,但它确实引用了 WindowsBase——不确定这是否意味着它与 Windows 耦合。
卫城
我不确定这是什么。是 MEF,还是即将到来的?
复合应用程序块
WPF 和 Winforms 复合应用程序块似乎提供了更多的工作台框架。我对这些几乎没有经验,但它们似乎在很大程度上依赖于 Guidance Automation,显然与 UI 层相结合。有几个将 MEF 与这些应用程序块相结合的示例。
我已经尽我所能在这里回答我自己的问题,但我真的只是在摸索表面,而且我对这些框架中的任何一个都没有经验。希望你们中的一些人可以添加有关您所使用的框架的更多细节。如果我们最终能得到某种比较矩阵,那就太好了。