Service OSGi服务-最佳实践

我开始越来越喜欢OSGi服务，并希望将更多的组件实现为服务。现在我正在寻找最佳实践，尤其是UI组件

对于听众关系，我使用白板模式，这是最好的方法。然而，如果我想要的不仅仅是通知，我可以想出三种可能的解决方案

想象一下以下场景：

interface IDatabaseService {
  EntityManager getEntityManager();
}

[1]白板图案-具有自我设置服务

我将创建一个新的服务接口：

interface IDatabaseServiceConsumer {
  setDatabaseService(IDatabaseService service);
}

并使用如下bindConsumer方法创建声明性IDatabaseService组件

protected void bindConsumer(IDatabaseServiceConsumer consumer) {
 consumer.setDatabaseService(this);
}
protected void unbindConsumer(IDatabaseServiceConsumer consumer) {
 consumer.setDatabaseService(null);
}

这种方法假设只有一个IDatabaseService

[Update]用法如下：

class MyUIClass ... {

private IDatabaseService dbService;

Consumer c = new IDatabaseServiceConsumer() {
 setDatabaseService(IDatabaseService service) {
  dbService = service;
 }
}
Activator.registerService(IDatabaseServiceConsumer.class,c,null);
...
}

[2]让我的班级成为a级服务

把一个班级想象成

公共类DatabaseEntryViewer扩展了TableViewer

现在，我只需为IDatabaseService添加绑定/取消绑定方法，并添加component.xml和DatabaseEntryViewer。这种方法假设有一个无参数构造函数，我通过OSGi服务工厂创建UI组件

[3]经典方式：ServiceTracker

在我的Activator中注册静态ServiceTracker并访问它的经典方法。使用跟踪器的类必须处理动态跟踪

---

目前我倾向于使用第一种方法，因为这种方法不会使对象创建复杂化，也不会将激活器从无休止的静态ServiceTracker中拯救出来。

我必须同意@Neil Bartlett的观点，您的选项1是向后的。实际上，您使用的是观察者/可观察模式

第2条是行不通的，因为在RCP中管理UI对象生命周期的方式不允许您做您想做的事情。小部件必须作为某种视图容器（ViewPart、Dialog等）初始化的一部分创建。此视图部件通常通过工作台/插件机制进行配置和管理。你应该用这个，而不是反对它

第三个选择很简单，不一定是最好的，但很简单

如果您使用，那么您可以轻松完成第2项。它提供了一种将服务bean注入UI视图、页面等的方法。您可以使用spring工厂创建视图（如plugin.xml中定义的），视图通过spring配置进行配置，spring配置能够将您的服务注入bean

---

您还可以将SpringExtensionFactory类使用的技术与DI结合起来，以完成相同的任务，而无需引入另一项技术。我自己还没有尝试过，所以我无法对困难做出评论，尽管如果我还没有使用Spring DM，我会尝试这样做来弥合RCP和OSGi之间的差距。

我不明白，为什么你不将IDatabaseService“注入”（绑定）到IDatabaseServiceConsumer？嗨，Ivan，目前我们没有使用任何DI框架，比如SpringDI或GoogleJuice。这对EclipseRCP开发来说是一条艰难的道路吗？您还没有提到您真正想要实现的目标。这三种方法都是有效的，但不可能说什么是最好的，因为没有上下文。。。。话虽如此，第一种方法似乎毫无意义。事实上，这是一种倒退，为什么要将消费者注入提供商？关于你对伊万的问题。。。为什么您认为您需要Spring或Guice来进行注射？？声明性服务为您提供了注入（也称为“绑定”）。我的主要目标是在由EclipseRCP框架实例化的UI组件中使用我的服务。这就是为什么我不能使用声明性服务。第一种方法是“注入”服务的不太优雅的工作区。我读了一些关于Spring依赖注入的内容，发现DI机制的工作原理与IMHO类似，接近2。