我建议你看一下JSR 296 - 虽然它还没有完全完成,但我认为它在提供每个Java GUI应用程序都需要的某些核心功能方面达到了最佳效果,而不会强制你生活在过于复杂的框架中。
我已成功使用JSR 296创建了一个中型应用程序。 对于此应用程序中的窗口布局,我们使用
MyDoggy(强烈推荐)。 对于布局管理,我们使用MiGLayout(超级推荐)。 对于数据绑定,我们使用JSR 295的修改形式(我们在JSR 295之上实现了类似于
PresentationModel的东西,用于GUI绑定)。 我正在将Guice作为DI机制并入,但尚未完成该工作(到目前为止,我认为它会与JSR 296“很好地”协同工作,只需要进行一些微调)。 让我们看看......持久性是这里的重要缺失环节-我目前正在评估
Simple以进行XML持久化,但在将其与像Guice这样的DI容器一起使用时遇到了问题。 我已经使
Betwixt正常运行,但对Betwixt的依赖关系非常巨大,因此我们正在寻找更简化的替代方案。
关于 Java 的其他 RCP 选项的看法:
NetBeans:
我对 NetBeans 使用的方法有一些基本哲学上的反对意见(对我来说,使用了太多设计反模式)。最终,这个框架会迫使你做出糟糕的设计决策 - 如果你不使用 NetBeans 作为你的 IDE,它几乎是不可能使用的(我尝试过,但我就是无法从 Eclipse 切换到 NB)。也许只是我个人的问题,但似乎应该可以为 RCP 框架编写代码,而不使用大量复杂的向导和自动生成的代码和 XML 文件。我花了很多时间去解决由 Visual Studio 生成的旧的 Visual C++ 代码,因此我非常谨慎任何无法手工编码的框架。
Spring RCP:
Spring 的团队有一个很好的稳定设计,但文档真的非常、非常薄弱。要快速掌握它还是相当困难的(但一旦你掌握了它,你可以很快地完成任务)。
Eclipse RCP:
由于部署开销较大,我们没有使用Eclipse(这取决于您的目标受众-对我们来说,额外部署50 MB的运行时程序不起作用)。毫无疑问,如果您的应用程序需要重要的插件功能,则Equinox是一个美妙的东西(当然,您也可以使用JSR 296运行Equinox,或使用类似于OSGi推广的Whiteboard模式的设计模式)。