Услуги OSGi - лучшая практика - PullRequest
Новая
       17

Услуги OSGi - лучшая практика

3 голосов
/ 27 октября 2011

Я начинаю любить сервисы OSGi все больше и больше и хочу реализовать свои компоненты как сервисы.Сейчас я ищу лучшие практики, особенно для компонентов пользовательского интерфейса.

Для отношений со слушателем я использую шаблон доски, который, по мнению ИМХО, является наилучшим подходом.Однако если мне нужно больше, чем просто уведомления, я могу подумать о трех возможных решениях.

Представьте себе следующий сценарий: 

interface IDatabaseService {
  EntityManager getEntityManager();
}

[1] Whiteboard Pattern - с функцией автоматической настройки

Я бы создал новый интерфейс службы: 

interface IDatabaseServiceConsumer {
  setDatabaseService(IDatabaseService service);
}

и создал бы декларативный компонент IDatabaseService с методом bindConsumer , подобным этому 

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

Этот подход предполагает, что существует только один IDatabaseService.

[Обновление] Использование будет выглядеть следующим образом: 

class MyUIClass ... {

private IDatabaseService dbService;

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

[2] Сделать мойclass a service

Изображение класса, подобного

открытый класс DatabaseEntryViewer расширяет TableViewer

Теперь я просто добавляю методы привязки / отсоединения для моей IDatabaseService и добавляю компонент.XML и добавить мой DatabaseEntryViewer.Этот подход предполагает, что существует конструктор без аргументов, и я создаю компоненты пользовательского интерфейса через OSGi-Service-Factory.

[3] Классический способ: ServiceTracker

Классический способ зарегистрировать статический ServiceTracker в моем Активаторе и получить к нему доступ.Класс, который использует трекер, должен обрабатывать динамику.

В настоящее время я предпочитаю первый, так как этот подход не усложняет создание объекта и спасает Активатор от бесконечных статических ServiceTrackers.

1 Ответ

2 голосов
/ 31 октября 2011

Я должен согласиться с @Neil Bartlett, ваш вариант 1 обратный.По сути, вы используете шаблон Observer / Observable.

Номер 2 не будет работать, поскольку способ управления жизненными циклами объектов пользовательского интерфейса в RCP не позволит вам делать то, что вы хотите.Виджет должен быть создан как часть инициализации контейнера вида (ViewPart, Dialog, ...).Эта часть представления обычно настраивается и управляется с помощью механизма Workbench / plugin.Вы должны работать с этим, а не против него.

Номер 3 будет простым вариантом, не обязательно лучшим, но простым.

Если вы используете Spring DM ,тогда вы легко сможете выполнить номер 2. Он предоставляет средства для внедрения ваших служебных компонентов в представления пользовательского интерфейса, страницы и т. д. Вы используете фабрику пружин для создания ваших представлений (как определено в вашем plugin.xml), которые настраиваются черезКонфигурация Spring, которая способна внедрять ваши сервисы в компонент.

Вы также можете комбинировать технику, используемую классом SpringExtensionFactory, с DI для достижения той же цели, не вводя другую технологию.Я сам не пробовал, поэтому не могу прокомментировать трудности, хотя я бы попытался преодолеть разрыв между RCP и OSGi, если я еще не использовал Spring DM.

...