Рекомендации по Eclipse 4 DI

Question

Я хотел бы знать, какие лучшие практики для инъекций зависимостей Eclipse 4. Прочитав об этом в Интернете, я придумал следующую стратегию.

требование

Share модель данных приложения (например, компания, сотрудник, клиент, ...), так что каркасные объекты (вид часть, обработчики, слушатели, ...) могут получить к нему доступ как можно меньше сцепления.

планируемая стратегия

• Я использовал плагин свойство lifeCycleURI зарегистрировать обработчик, который срабатывает при запуске приложения. Такой обработчик создает «пустой» контейнерный объект модели данных верхнего уровня и помещает его в EclipseContext. Он также отбрасывается, когда приложение останавливается.

• Все классы каркаса Eclipse (части обзора, обработчики) используют классический DI для ввода объекта модели данных.

• У прослушивателей кнопок, созданных с помощью конструктора классов, не может быть введен в них объект модели данных. Поэтому я думал, что они могут быть созданы с помощью ContextInjectionFactory.make(), чтобы выполнить инъекцию. Это соединило бы класс, который создает слушателя с CIF, но большим преимуществом является то, что инъекция работает из коробки.

Это лучшее решение, которое я нашел еще, чтобы использовать E4 DI с минимальным сцеплением. Слабое место, на мой взгляд, связано с CIF. Мой вопрос будет заключаться в том, существует ли какая-либо стратегия для удаления даже этой связи или альтернативных решений для тех же требований.

Answer 1

Вы можете создать класс обслуживания в своем проекте, допустим, ModelService.

Добавить @creatable и @singleton аннотации к этому классу:

@creatable 
@singleton 
class ModelService{ 

} 

И пусть DI делать свою работу, используя следующий синтаксис в ваших частей/обработчиков/и т.д ..

@Inject ModelService modelService; 

Тогда вы можете применяйте методы в своей службе, такие как «createBaseModel()», updateModel() и т. д.

Это создает решение с низкой связью: вы также можете реализовать ModelService в отдельном плагине и определить его как службу OSGi. для этого решения вы можете прочитать this Lars Vogel article.