Лучшие практики реализации Java Delegate в Camunda: Spring Bean vs прямое создание класса?
Я работаю с Camunda BPMN и Java 8 и столкнулся с двумя разными подходами реализации Java delegates в сервисных задачах. Хочу понять, какой подход считается лучшей практикой и почему.
Подход 1: Внедрение через Spring Bean
<serviceTask id="SampleDelegateST" camunda:delegateExpression="${sampleDelegate}"/>
Соответствующий Spring компонент:
@Component("sampleDelegate")
public class SampleDelegate implements JavaDelegate {
@Autowired
private SomeService service;
@Override
public void execute(DelegateExecution execution) throws Exception {
// бизнес-логика
}
}
Подход 2: Прямое создание класса
<serviceTask id="SampleDelegateV2ST" camunda:class="ru.schoolservice.arm.delegate.SampleDelegateV2"/>
Соответствующий Spring компонент:
public class SampleDelegateV2 implements JavaDelegate {
@Override
public void execute(DelegateExecution execution) throws Exception {
// бизнес-логика без DI
}
}
Мои вопросы:
- Какой подход считается текущей лучшей практикой в Camunda и почему?
- Какие конкретные преимущества/недостатки у каждого метода?
- Есть ли конкретные сценарии, где один подход предпочтительнее другого?
Ответы (1 шт):
Вы, в целом, сами ответили на свой вопрос, предоставив примеры кода.
Когда вы используете camunda:class вы говорите, что есть некоторый класс. Camunda может создать объект этого класса, используя только публичный конструктор по-умолчанию. Это решение подойдёт, если вам в вашем делегате не нужны зависимости от других сервисов. В общем что-то очень простое.
При использовании camunda:delegateExpression вы сообщаете системе, что есть некоторый объект с указанным именем. Сама Camunda не знает и не управляет жизненным циклом этого объекта, вы перепоручили это Spring. Он сам создаст bean этого объекта и вызовет когда нужно (а, возможно, ещё и закроет/удалит его, а может, пересоздаст и т.п.). Spring в свою очередь умеет DI, т.е. с ним уже может быть создан делегат со сложными зависимостями (другими сервисами, репозиториями и пр.)