이벤트는 GUI 프로그래밍에만 사용됩니까?

이벤트는 GUI 프로그래밍에만 사용됩니까?

이 다른 일이 일어날 때 정상적인 백엔드 프로그래밍에서 어떻게 처리합니까?

아니. Observers를 구현하고 클래스를 수정하기에 매우 편리합니다.

새로운 사용자를 등록하는 방법이 있다고 가정 해 봅시다.

public void Register(user) {
    db.Save(user);
}

그런 다음 누군가 이메일을 보내도록 결정합니다. 우리는 이것을 할 수 있습니다 :

public void Register(user) {
    db.Save(user);
    emailClient.Send(new RegistrationEmail(user));
}

그러나 우리는 방금 수정해야 할 클래스를 수정했습니다. 이 간단한 의사 코드에는 적합하지만 프로덕션 코드에서 광기를 피할 수 있습니다. 이 방법이 새로운 사용자를 만드는 원래 목적과 거의 관련이없는 30 줄의 코드 일 때까지 얼마나 걸립니까?

수업에서 핵심 기능을 수행하고 사용자가 등록한 것을 듣고있는 사람에게 알리는 이벤트를 발생시키는 것이 훨씬 좋으며, 필요한 조치 (예 : 이메일 보내기)를 수행 할 수 있습니다.

public void Register(user) {
    db.Save(user);

    RaiseUserRegisteredEvent(user);
}

이를 통해 코드를 깨끗하고 유연하게 유지할 수 있습니다. 종종 간과되는 OOP 중 하나는 클래스 가 서로 에게 메시지 를 보내는 것 입니다. 이러한 메시지는 이벤트입니다.

아니.

비 GUI 논리에서 사용되는 이벤트의 전형적인 예는 데이터베이스 트리거입니다.

트리거는 주어진 이벤트가 발생할 때 실행되는 코드입니다 (INSERT, DELETE 등). 나에게 이벤트처럼 보인다.

이것은 이벤트의 위키 백과 정의입니다.

컴퓨팅에서, 이벤트는 소프트웨어에 의해 처리 될 수있는 소프트웨어에 의해 인식되는 동작 또는 발생이다. 컴퓨터 이벤트는 시스템, 사용자 또는 다른 방법으로 생성하거나 트리거 할 수 있습니다. 일반적으로 이벤트는 프로그램 흐름과 동 기적으로 처리됩니다. 즉, 소프트웨어에는 이벤트가 처리되는 하나 이상의 전용 장소, 종종 이벤트 루프가있을 수 있습니다. 이벤트 소스에는 예를 들어 키보드의 키 입력을 통해 소프트웨어와 상호 작용할 수있는 사용자가 포함됩니다. 다른 소스는 타이머와 같은 하드웨어 장치입니다. 소프트웨어는 또한 예를 들어 작업 완료를 알리기 위해 자체 이벤트 세트를 이벤트 루프로 트리거 할 수 있습니다. 이벤트에 응답하여 동작을 변경하는 소프트웨어는 종종 대화 형이라는 목표를 가진 이벤트 중심이라고합니다.

모든 이벤트가 사용자 생성되는 것은 아닙니다. 일부는 앞에서 언급 한 데이터베이스 INSERT의 crontab과 같은 타이머에 의해 생성됩니다.

이 정의는 또한 일부 프로그램이나 시스템이 "대화 형을 목표로하는 이벤트 중심"이라고 말하며,이를 통해 이벤트의 목적 또는 유용성이 전적으로 GUI가 아닌 대화 형 기능을 제공한다는 것을 알 수 있습니다. 반드시 GUI는 아니지만 CLI 프로그램도 대화식이 될 수 있습니다.

이벤트 기반 프로그래밍은 실제로 고성능 서버 프로그래밍에도 사용됩니다.

일반적인 서버 워크로드에서 결과를 처리하는 데 많은 시간이 실제로 I / O에서 발생합니다. 예를 들어 (7200RPM) 하드 디스크 드라이브에서 데이터를 가져 오는 데 최대 8.3ms가 걸릴 수 있습니다. 최신 GHz 프로세서의 경우 최대 백만 클럭 사이클에 해당합니다. CPU가 매번 데이터를 기다리면 (아무것도하지 않음) 많은 클럭 사이클을 잃게됩니다.

전통적인 프로그래밍 기술은 여러 스레드 를 도입하여이 문제를 해결 합니다 . CPU는 수백 개의 스레드를 동시에 실행하려고합니다. 그러나이 모델의 문제점은 CPU가 스레드를 전환 할 때마다 컨텍스트 전환에 수백 개의 클럭 사이클이 필요하다는 것 입니다. 컨텍스트 스위치는 CPU가 스레드 로컬 메모리를 CPU 레지스터에 복사 하고 이전 스레드의 레지스터 / 상태를 RAM에 저장하는 경우입니다.

또한 각 스레드는 상태를 저장하기 위해 특정 양의 메모리를 사용해야합니다.

오늘날에는 단일 스레드가 있고 루프에서 실행되는 서버에 대한 푸시가 있습니다. 그런 다음 작업 조각이 메시지 펌프 로 푸시되어 단일 스레드의 큐 역할을합니다 (UI 스레드와 유사). CPU는 작업이 완료되기를 기다리는 대신 하드 디스크 드라이브 액세스와 같은 작업에 콜백 이벤트를 설정합니다. 컨텍스트 전환을 줄입니다.

이러한 서버의 가장 좋은 예는 Node.js 이며, 이는 겸손한 하드웨어로 백만 개의 동시 연결을 처리 할 수있는 반면 Java / Tomcat 서버는 수천에서 어려움을 겪습니다.

이벤트는 네트워크 프로그래밍 (예 : Nginx)에서 많이 사용되어 값 비싼 통화 대기 루프를 피하고 대신 특정 작업이 가능한시기 (I / O, 긴급 데이터 등)를 정확하게 알 수있는 깔끔한 인터페이스를 제공합니다 . 이것은 또한 C10k 문제에 대한 해결책 입니다.

기본 아이디어는 이벤트, 모든 이벤트 또는 특히 관심있는 일부 (예를 들어 읽을 수있는 데이터)를 모니터링하기 위해 OS에 소켓 세트 (예 : 네트워크 연결)를 제공하는 것입니다. 이러한 활동이 목록의 소켓 중 하나에서 운영 체제에 의해 감지되면 API에서 찾고 있던 이벤트에 대한 알림을 받게됩니다. API에서 발생한 이벤트를 정렬하고 그에 따라 조치를 취해야합니다. .

이제 이것은 저수준의 추상적 인 관점이며, 더 잘 확장하기가 까다 롭습니다. 그러나 크로스 플랫폼 방식으로 처리하는 상위 레벨의 프레임 워크가 많이 있습니다 .Twisted for Python, Boost.Asio for C ++ 또는 libevent for C가 떠 오릅니다.

임베디드 시스템은 명시 적으로 프로그래밍되지 않더라도 거의 항상 본질적으로 이벤트 중심입니다.

이러한 이벤트는 하드웨어 인터럽트, 버튼 누름, 기간 아날로그-디지털 판독 값, 타이머 만료 등과 같은 것에서 발생합니다.

저전력 임베디드 시스템은 이벤트 중심 일 가능성이 훨씬 높습니다. 그들은 대부분의 시간을 잠들고 (CPU는 저전력 모드에서 잠자기), 무언가 일어나기를 기다립니다 ( "뭔가"는 이벤트입니다).

이벤트 중심 임베디드 시스템의 가장 일반적이고 널리 사용되는 프레임 워크 중 하나는 Quantum Platform (QP)입니다 (QP는 Linux, Windows 및 모든 유닉스 계열 OS에서도 작동합니다). 상태 머신은 이벤트 중심 프로그래밍에 자연스럽게 적합합니다. 프로그램은 일반적인 의미에서 "순차적"이 아니기 때문에 시스템 상태 및 현재 이벤트에 따라 호출되는 "콜백"세트입니다.

이벤트 메시지 Gregor Hohpe.

이벤트 중심 아키텍처 Gregor Hohpe.

SEDA 아키텍처 , 웨일스 어, 컬러, 브루어.

다른 일이 일어날 때 정상적인 백엔드 프로그래밍에서 어떻게 처리합니까?

유한 상태 머신 은 하나의 일반적인 접근 방식입니다

Given(State.A)
When(Event.B)
Then(State.C)
    .and(Consequences.D)

임베디드 시스템에서 이벤트는 인터럽트 중에 발생합니다. 타이머에서 I / O에 이르기까지 많은 인터럽트 소스가 있습니다.

또한 RTOS에도 이벤트가있을 수 있습니다. 한 가지 예는 다른 작업에서 메시지를 기다리는 것입니다.

임베디드 시스템이 아니지만 C #에서 수행 한 작업은 SCADA 시스템이었습니다. 로드가 시스템 생성 이벤트의 일부로 언로드되고 다른 부분이 데이터베이스에 새로운 상태를 기록 할 때웨어 하우스에서 발생한 것과 연관된 많은 이벤트가있었습니다. 물론 GUI 클라이언트가 있었지만웨어 하우스의 상태를 반영한 ​​데이터베이스의 상태 만 표시했습니다. 따라서 이벤트 및 스레딩을 기반으로하는 백엔드 서버 소프트웨어였습니다. 개발하기가 매우 어렵습니다.

https://ko.wikipedia.org/wiki/SCADA