Есть ли преимущества использования делегата выражения над классом Java в camunda?
Единственное, что я могу представить с использованием делегатов выражений над классами Java, - это то, что всякий раз, когда мой собственный класс кода требуется для загрузки из Spring beans с использованием внедрение зависимости, особенно там, где вы хотите управлять жизненным циклом экземпляра делегирования вашим приложением, а не движком времени выполнения Camunda.
Проще говоря, используя делегаты выражений, мы можем инициализировать класс делегата, как мы хотим, используя Spring DI, не позволяя движку Camunda инициализировать его. И воспользуйтесь всеми преимуществами DI.
Сценарий состоит в том, что мы хотим загрузить наш класс делегирования из Spring beans, где он требует внедрения зависимостей времени выполнения перед запуском нашего кода делегирования. Итак, мы можем использовать компоненты Spring для инициализации зависимостей других объектов и создания компонента, ссылающегося на класс делегирования, внедряющий другие инициализированные компоненты. Например,
<serviceTask id = "paymentTask" camunda:delegateExpression = "${myPaymentBean}" />
Вышеупомянутый myPaymentBean
разрешен из spring, и это будет экземпляр JavaDelegate
, который уже инициализирован необходимыми зависимостями посредством внедрения зависимостей (DI). Мы использовали DI, потому что наша бизнес-логика должна быть тщательно протестирована перед запуском в производство, и на ее основе проще написать автоматизированные тесты.
Если вы используете классы Java, то инициализация экземпляра будет выполняться механизмом camunda, и есть ограничение, что должен быть общедоступный конструктор по умолчанию. Это очень ограничено, поскольку большинство практических приложений имеют зависимости и должны быть уже инициализированы до кода. Либо вы должны сделать свои зависимости одиночными (что я никогда не рекомендую), либо использовать фабрики для создания экземпляров до кода (что неэффективно и труднее тестировать).
Надеюсь, это проясняет ваш вопрос.