노드에서 이벤트를 사용합니다.정확한 방법

이벤트 드라이브 프로그래밍이 유행하기 전에 응용 프로그램의 다른 부분 간에 통신하는 표준 방식은 매우 간단합니다. 다른 구성 요소에 메시지를 보내는 구성 요소가 이 구성 요소를 현저하게 호출하는 방법을 원합니다.그러나 이벤트 구동 코드는 호출된 것이 아니라 응답하기 위해 작성된 것이다.

경기의 이점

이런 방법은 우리의 구성 요소를 더욱 결합시켰다.기본적으로, 우리가 프로그램을 계속 작성할 때, 우리는 그 과정에서 사건을 식별하고, 정확한 시간에 그것들을 촉발하며, 모든 사건에 하나 이상의 사건 탐지기를 추가할 것이다.확장 기능은 특정 이벤트에 더 많은 탐지기를 추가하기만 하면 기존 탐지기나 이벤트를 터치하는 프로그램 부분을 수정할 필요가 없기 때문에 훨씬 쉬워졌다.우리가 말한 것은 기본적으로 관찰자 모델이다.

자료 출처: https://www.dofactory.com/javascript/observer-design-pattern

이벤트 기반 아키텍처 설계

이벤트를 식별하는 것은 매우 중요합니다. 시스템에서 기존 이벤트를 삭제하거나 교체해야 하는 것을 원하지 않기 때문에 이벤트에 추가된 모든 탐지기를 삭제하거나 수정할 수 있습니다.내가 사용하는 일반적인 원칙은 업무 논리 단원이 실행을 마칠 때만 트리거 사건을 고려하는 것이다.
만약 사용자가 등록한 후에 일련의 다른 전자 우편을 보내고 싶다면.현재 등록 과정 자체는 많은 복잡한 절차, 조회 등과 관련될 수 있지만 상업적인 측면에서 볼 때 이것은 단지 하나의 절차일 뿐이다.보내는 모든 우편물은 별도의 절차이다.따라서 등록이 끝난 후 즉시 이벤트를 시작하고 여러 개의 탐지기를 이 이벤트에 연결하면 탐지기마다 하나의 유형의 전자메일을 보내는 것이 의미가 있다.
"Node의 비동기식 이벤트 제어 아키텍처는""송신기""라는 특정 유형의 객체를 가지고 있으며, 명명된 이벤트를 실행하여""리스너""라는 함수를 호출합니다."모든 발송 사건의 대상은 EventEmitter류의 실례이다.그것을 사용하면 우리는 자신의 이벤트를 만들 수 있다.

하나의 예

내장형 events 모듈을 사용하여 EventEmitter에 액세스해 보겠습니다.

// my_emitter.js

const EventEmitter = require('events');

const myEmitter = new EventEmitter();

module.exports = myEmitter;

이것은 응용 프로그램의 일부이며, 우리 서버는 HTTP 요청을 받아 새 사용자를 저장하고 이벤트를 보냅니다.

// registration_handler.js

const myEmitter = require('./my_emitter');

// Perform the registration steps

// Pass the new user object as the message passed through by this event.
myEmitter.emit('user-registered', user);

또 하나의 별도의 모듈이 있는데, 우리는 그중에 탐지기를 추가한다.

// listener.js

const myEmitter = require('./my_emitter');

myEmitter.on('user-registered', (user) => {
  // Send an email or whatever.
});

정책과 실시를 분리하는 것은 좋은 방법이다.이런 상황에서 전략은 어떤 탐지기가 어떤 사건을 구독했는지, 실현은 탐지기 자체를 의미한다.

// subscriptions.js

const myEmitter = require('./my_emitter');
const sendEmailOnRegistration = require('./send_email_on_registration');
const someOtherListener = require('./some_other_listener');


myEmitter.on('user-registered', sendEmailOnRegistration);
myEmitter.on('user-registered', someOtherListener);

// send_email_on_registration.js

module.exports = (user) => {
  // Send a welcome email or whatever.
}

이 분리는 탐지기도 같은 메시지를 보내는 다른 이벤트 (사용자 대상) 에 추가할 수 있도록 해 준다.여러 탐지기가 하나의 이벤트에 연결되면 연결 순서에 따라 동기화된다는 점도 지적해야 한다.이에 따라 someOtherListener은 sendEmailOnRegistration에서 실행이 완료된 후 실행될 예정이다.
그러나 탐지기가 비동기적으로 작동하기를 원한다면 setImmediate으로 간단하게 포장할 수 있다. 다음과 같다.

// send_email_on_registration.js

module.exports = (user) => {
  setImmediate(() => {
    // Send a welcome email or whatever.
  });
}

청중의 정결을 유지하다

청중에게 편지를 쓸 때 단일 책임 원칙을 고수한다. 청중은 한 가지 일만 하고 그것을 잘 해야 한다.예를 들어 감청기에서 너무 많은 조건문을 작성하는 것을 피하고 이벤트가 전송하는 데이터(메시지)에 따라 무엇을 해야 할지 결정한다.이 경우 다른 이벤트를 사용하는 것이 좋습니다.

// registration_handler.js

const myEmitter = require('./my_emitter');

// Perform the registration steps

// The application should react differently if the new user has been activated instantly.
if (user.activated) {
  myEmitter.emit('user-registered:activated', user);

} else {
  myEmitter.emit('user-registered', user);
}

// subscriptions.js

const myEmitter = require('./my_emitter');
const sendEmailOnRegistration = require('./send_email_on_registration');
const someOtherListener = require('./some_other_listener');
const doSomethingEntirelyDifferent = require('./do_something_entirely_different');


myEmitter.on('user-registered', sendEmailOnRegistration);
myEmitter.on('user-registered', someOtherListener);

myEmitter.on('user-registered:activated', doSomethingEntirelyDifferent);

필요할 때 명확하게 분리탐지기

앞의 예에서 우리의 탐지기는 완전히 독립된 함수이다.그러나 탐지기가 대상과 연결된 경우 구독 이벤트와 수동으로 분리해야 한다.그렇지 않으면 대상은 영원히 쓰레기로 수집되지 않을 것이다. 왜냐하면 대상의 일부 (탐지기) 는 외부 대상 (발사기) 에 계속 인용되기 때문이다.따라서 메모리 유출 가능성은 희박하다.
예를 들어, 채팅 애플리케이션을 구축하고 있으며 사용자가 연결된 채팅방에서 새 메시지를 받을 때 알림을 표시하고자 하는 책임이 해당 사용자 객체 자체에 있어야 하는 경우 다음과 같이 할 수 있습니다.

// chat_user.js

class ChatUser {

  displayNewMessageNotification(newMessage) {
    // Push an alert message or something.
  }

  // `chatroom` is an instance of EventEmitter.
  connectToChatroom(chatroom) {
    chatroom.on('message-received', this.displayNewMessageNotification);
  }

  disconnectFromChatroom(chatroom) {
    chatroom.removeListener('message-received', this.displayNewMessageNotification);
  }
}

사용자가 자신의 옵션 카드를 닫거나 인터넷 연결을 한동안 잃을 때, 우리는 당연히 서버에서 리셋을 시작하여 다른 사용자 중 한 명이 방금 오프라인 상태임을 알릴 것이다.이 점에서 오프라인 사용자를 위해 displayNewMessageNotification을 호출하는 것은 물론 아무런 의미가 없지만, 우리가 명확하게 삭제하지 않는 한 새로운 메시지에서 계속 호출될 것이다.만약 우리가 이렇게 하지 않는다면, 불필요한 호출을 제외하고, 사용자 대상도 무기한으로 메모리에 남을 것이다.따라서 서버측 콜백에서 disconnectFromChatroom을 호출하여 사용자가 오프라인일 때마다 이 콜백을 실행하도록 하십시오.

한복판

만약 우리가 조심하지 않는다면 이벤트 구동 구조의 느슨한 결합도 복잡성을 증가시킬 것이다.추적 시스템의 의존 관계는 어떤 탐지기가 최종적으로 어떤 사건을 집행할지 매우 어려울 수 있다.만약 우리가 탐지기에서 사건을 보내기 시작한다면, 일련의 의외의 사건을 일으킬 수 있으며, 우리 프로그램은 특히 이 문제를 일으키기 쉽다.