Explication détaillée basée sur les événements Springboot

composition événementielle printanière

L'entraînement à ressort se compose de 3 parties

1. ApplicationEvent: indique l'événement lui-même, les événements personnalisés doivent hériter de cette classe. Utilisé pour définir des événements

2. ApplicationEventPublisherAware: expéditeur de l'événement, vous devez implémenter cette interface. Principalement utilisé pour publier des événements. ApplicationContext implémente également cette interface, qui peut être utilisée pour publier des événements.

Après Spring 4.2, ApplicationEventPublisher est automatiquement injecté dans le conteneur et peut être obtenu à l'aide d'Autowired.

3. ApplicationListener: interface d'écoute d'événement. La classe d'écouteur peut implémenter la méthode onApplicationEvent dans ApplicationListener.

Après le printemps 4.2, nous pouvons surveiller la publication des événements de manière plus concise. Pour surveiller les événements, nous n'avons plus besoin d'implémenter l'interface ApplicationListener, il suffit d'ajouter l'annotation @EventListener à la méthode.

Étapes d'utilisation

L'utilisation d'événements dans Spring est très simple, seules les étapes suivantes sont requises:

  1. Définir des événements, hériter d'ApplicationEvent
  2. Pour définir l'écouteur, implémentez l'interface ApplicationListener ou ajoutez l'annotation @EventListener à la méthode
  3. Pour publier un événement, appelez ApplicationContext.publishEvent () ou ApplicationEventPublisher.publishEvent ();

Définir l'événement

public class OrderCreateEvent extends ApplicationEvent {
    
    

    private final Order order;

    public OrderCreateEvent(Object source, Order order) {
    
    
        super(source);
        this.order = order;
    }

    public Order getOrder() {
    
    
        return order;
    }
}

Envoyer un événement: méthode publishEvent ()

    @Autowired
    private ApplicationEventPublisher applicationEventPublisher;

    public void save(Order order) {
    
    
        //生成订单号
        String orderNo = getOrderNo();
        order.setOrderNo(orderNo);
        log.info("订单保存成功:" + order);
        //发布订单创建事件
        applicationEventPublisher.publishEvent(new OrderCreateEvent(this, order));
    }

Il y a 2 façons de réaliser l'observateur

La première façon: implémenter l'interface ApplicationListener

@Component
public class OrderCreateEventListener implements ApplicationListener<OrderCreateEvent> {
    
    
    @Override
    public void onApplicationEvent(OrderCreateEvent event) {
    
    
        System.out.printf("实现ApplicationListener接口,监听OrderCreateEvent事件");
    }
}

La deuxième façon: via l'annotation @EventListener, il surveillera automatiquement la publication de l'événement correspondant en fonction du type de paramètre de la méthode.

@Component
@Slf4j
public class OrderCreateEventListener3 {

    @EventListener (classes = {OrderCreateEvent.class}) //classes属性指定处理事件的类型
    @Async //异步监听
    @Order(0)//使用order指定顺序,越小优先级越高
    public void eventListener(OrderCreateEvent event) {
        log.info("通过注解@EventListener和@Async,异步监听OrderCreateEvent事件,orderId:" + event.getOrder().getOrderNo());
    }
}

Si vous souhaitez surveiller la publication de plusieurs types d'événements, vous pouvez le spécifier dans @EventListener (classes = {FaceEvent.class, ArmEvent.class}). Spring appellera cette méthode plusieurs fois pour gérer plusieurs événements. Mais notez qu'à l'heure actuelle, il ne peut pas y avoir plusieurs paramètres de méthode, sinon une exception de conversion se produira. Vous pouvez utiliser la classe parente de plusieurs événements comme seul paramètre de méthode pour recevoir et traiter les événements, mais il n'est pas recommandé de surveiller la publication de plusieurs événements, sauf si nécessaire. .

Si plusieurs écouteurs écoutent le même événement, nous pouvons utiliser l'annotation @order de spring sur la méthode pour définir l'ordre de plusieurs écouteurs. Plus l'ordre est petit, plus la priorité est élevée.

@EventListener a également un attribut. Les expressions SPEL peuvent être utilisées dans condition () pour filtrer et écouter les événements, c'est-à-dire que seuls ceux qui remplissent une certaine condition seront traités. tel que:

@EventListener(condition = "event.message == 'message'")

Surveillez plusieurs événements:

    @EventListener({
    
    FaceEvent.class,ArmEvent.class})
    public void onApplicationEvent3(Object event) {
    
    

        if(event instanceof FaceEvent){
    
    
            LOGGER.info("===> B 收到人脸事件:  {}",((FaceEvent) event).getEventData());
        }else if(event instanceof ArmEvent){
    
    
            ArmEvent armEvent = (ArmEvent) event;
            LOGGER.info("===> B 收到臂膀事件:  {}",armEvent.getEventData());
        }
    }

Précautions

  • Les auditeurs qui ne sont pas traités par l'événement seront ignorés.
  • Un événement peut être surveillé et traité par plusieurs classes de traitement de moniteur en même temps.
  • Par défaut, l'événement est synchrone, c'est-à-dire qu'une fois l'événement publié, il attendra que l'écouteur le traite. S'il y a une transaction dans l'entreprise où l'événement est publié, le traitement de l'auditeur sera également dans la même transaction.
  • Si vous ne souhaitez pas être affecté par le traitement des événements, vous pouvez ajouter @Async à la méthode onApplicationEvent pour prendre en charge asynchrone ou ajouter @Async à la méthode d'annotation avec @EventListener. Remarque: @EnableAsync doit être ajouté à la classe de démarrage en même temps

Utilisez @TransactionalEventListener pour obtenir l'isolation des transactions lors de la surveillance des événements

Dans de nombreux cas, nous publierons l'événement correspondant traitant une autre logique uniquement après la soumission de la transaction, comme l'envoi d'e-mails ou de SMS après l'inscription de l'utilisateur. À ce stade, vous pouvez utiliser l'annotation @TransactionalEventListener.

@TransactionalEventListener et @EventListener peuvent surveiller les événements, mais le premier peut effectuer une isolation transactionnelle sur les événements de publication et d'écoute .

@TransactionalEventListener est une extension de @EventListener, permettant aux écouteurs d'événements d'être liés à une certaine étape de la transaction. Peut être lié aux phases de transaction suivantes:

  • AFTER_COMMIT (par défaut), une fois la transaction validée
  • AFTER_ROLLBACK, après l'annulation de la transaction
  • AFTER_COMPLETION, la transaction est terminée, y compris après validation et annulation
  • BEFORE_COMMIT, avant que la transaction ne soit validée

@TransactionalEventListener signifie qu'il ne fait pas partie de la même transaction que la méthode qui publie l'événement. La méthode qui publie l'événement n'exécutera cette méthode de surveillance qu'après la fin de la transaction . Une exception dans la logique d'écoute n'annulera pas la transaction de la méthode qui publie l'événement .

@TransactionalEventListener a un attribut de fallbackExecution, la valeur par défaut est false , ce qui signifie que lorsque la méthode de publication d'événements n'a pas de contrôle de transaction, l'écouteur n'écoute pas les événements, c'est la situation par défaut! fallbackExecution = true, cela signifie que lorsque la méthode de publication de l'événement n'a pas de contrôle de transaction, la méthode d'écoute peut toujours écouter l'événement pour traitement.

Je suppose que tu aimes

Origine blog.csdn.net/kaihuishang666/article/details/107520480
conseillé
Classement