Лучшая практика для создания запланированных методов при весенней загрузке

Как лучше всего создавать планировщики из следующего (или вашего варианта):

1) Для одного запланированного метода создайте один компонент и вызовите службу из этого метода:

@Component
public class MyScheduler {

    private final MyService myService;

    public MyScheduler(MyService myService) {
        this.myService= myService;
    }

    @Scheduled(fixedDelay = 1L)
    public void process() {
     myService.startSomethig();
    }
}

2) Создайте один компонент для всех запланированных методов и запустите службу для конкретного метода:

@Component
public class MySchedulers {

    private final MyService1 myService1;
    private final MyService2 myService2;
    private final MyService3 myService3;

    public MySchedulers (MyService1 myService1, MyService2 myService2, MyService3 myService3) {
        this.myService1 = myService1;
        this.myService2 = myService2;
        this.myService3 = myService3;
    }

    @Scheduled(fixedDelay = 100L)
    public void process() {
     myService1.startSomethig();
    }

     @Scheduled(fixedDelay = 666L)
    public void process() {
     myService2.startAny();
    }

    @Scheduled(fixedDelay = 999L)
    public void process() {
     myService3.startAll();
    }
}

3) Создайте расписанный метод в каждом конкретном сервисе:

@Service
public class MyServiceImpl implements MyService {

     //filds, constructor

    @Scheduled(fixedDelay = 100L)
    public void process() {
       startSomethig();
    }

    @Transactional
    @Override
    public void startSomethig() {
        //...
    }

Какой подход лучше? может есть другие? Буду рад услышать ваше мнение

Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
3
0
1 121
2

Ответы 2

Лучшего пути нет, все «зависит».

1). Это похоже на то, что я обычно делаю - я создаю класс с именем, заканчивающимся на «Job», например «GenerateReportJob», у которого есть запланированный метод, который часто просто вызывает другой класс обслуживания.

2). Если у вас есть запланированные задания, которые используют одни и те же зависимости, и их цель связана друг с другом - нет ничего плохого в том, чтобы поместить их в один и тот же класс. Но вам следует избегать создания только одного класса для всех возможных запланированных заданий в вашем приложении - он быстро превратится в огромный файл с множеством зависимостей, о которых трудно рассуждать.

3). Я избегаю помещать @Scheduled непосредственно в методы обслуживания, так как мне трудно найти все задания в приложении. Технически это работает, но, на мой взгляд, не подходит для разработчиков.

Я предпочитаю и реализовал в своем проекте второй метод.

Основная причина выбора этого способа - централизованное управление для всех периодических задач. Запланированные задачи в моем проекте интенсивно используются в базе данных, и таким образом я могу предотвратить дублирование выполняемых заданий.

Вторая причина - это читаемость кода. Соавторам проще находить недавно добавленные запланированные задачи.

Наконец, я согласен с Мачеем. Лучшая модель для вас зависит от ваших задач и вашей точки зрения, чтобы создать хорошую структуру для вашего собственного проекта.

Другие вопросы по теме