¿Los eventos solo se usan para la programación de la GUI?

No. Son realmente útiles para implementar Observadores y asegurarse de que las clases estén cerradas a modificaciones.

Digamos que tenemos un método que registra nuevos usuarios.

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

Entonces alguien decide que se debe enviar un correo electrónico. Podríamos hacer esto:

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

Pero acabamos de modificar una clase que se supone está cerrada a la modificación. Probablemente esté bien para este simple pseudocódigo, pero probablemente sea el camino a la locura en el código de producción. ¿Cuánto tiempo falta para que este método tenga 30 líneas de código que estén apenas relacionadas con el propósito original de crear un nuevo usuario?

Es mucho más agradable dejar que la clase realice su funcionalidad principal y organizar un evento informando a quien esté escuchando que un usuario está registrado, y pueden tomar las medidas necesarias (como enviar un correo electrónico)

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

    RaiseUserRegisteredEvent(user);
}

Esto mantiene nuestro código limpio y flexible. Una de las piezas de OOP que a menudo se pasan por alto es que las clases se envían mensajes entre sí. Los eventos son estos mensajes.

No.

Un ejemplo clásico de eventos que se utilizan en lógica sin GUI son los activadores de base de datos.

Los disparadores son códigos que se ejecutan cuando ocurre un evento determinado (INSERTAR, BORRAR, etc.). Me parece un evento.

Esta es la definición de Wikipedia del evento:

  

En informática, un evento es una acción u ocurrencia reconocida por   Software que puede ser manejado por el software. Los eventos informáticos pueden ser   generados o activados por el sistema, por el usuario o de otra manera.   Normalmente, los eventos se manejan de forma síncrona con el flujo del programa,   es decir, el software puede tener uno o más lugares dedicados donde   los eventos son manejados, frecuentemente un bucle de eventos. Una fuente de eventos   incluye al usuario, que puede interactuar con el software mediante, por ejemplo,   Ejemplo, pulsaciones en el teclado. Otra fuente es un hardware.   dispositivo como un temporizador. El software también puede activar su propio conjunto de   eventos en el bucle de eventos, por ejemplo, Para comunicar la finalización de un   tarea. Se dice software que cambia su comportamiento en respuesta a eventos.   ser impulsado por eventos, a menudo con el objetivo de ser interactivo.

No todos los eventos son generados por el usuario. Algunos son generados por un temporizador como un crontab por una base de datos INSERTAR como mencioné anteriormente.

La definición también establece que algunos programas o sistemas son "impulsados por eventos, a menudo con el objetivo de ser interactivos" , de donde se puede deducir que el propósito o la utilidad de los eventos no son únicamente pero a menudo, para proporcionar interactividad (como las GUI, aunque no necesariamente las GUI, ya que los programas CLI también pueden ser interactivos).

La programación basada en eventos también se usa en realidad para la programación de servidores de alto rendimiento.

En una carga de trabajo típica del servidor, la mayor parte del tiempo que se procesa un resultado proviene de la E / S. Por ejemplo, extraer datos de una unidad de disco duro (7200 RPM) puede llevar hasta 8,3 ms. Para un procesador moderno de GHz, eso equivaldría a ~ 1 millón de ciclos de reloj. Si una CPU esperara los datos cada vez (sin hacer nada), perderíamos MUCHOS ciclos de reloj.

Las técnicas de programación tradicionales solucionan esto al introducir múltiples subprocesos . La CPU intenta ejecutar cientos de hilos al mismo tiempo. Sin embargo, el problema que tiene este modelo es que, cada vez que una CPU cambia de tema, requiere cientos de ciclos de reloj para cambio de contexto . Un cambio de contexto es cuando la CPU copia la memoria del subproceso local en los registros de la CPU y también almacena el registro / estado del subproceso anterior en la memoria RAM.

Además, cada subproceso debe utilizar una cierta cantidad de memoria para almacenar su estado.

Hoy en día, ha habido un impulso para los servidores que tiene un solo hilo, que se ejecuta en un bucle. Luego, los trabajos se insertan en un bomba de mensajes , que actúa como una cola para el único hilo (como en una interfaz de usuario hilo). En lugar de esperar a que finalice el trabajo, la CPU establece un evento de devolución de llamada, para cosas como acceso a la unidad de disco duro. Lo que reduce el cambio de contexto.

El mejor ejemplo de este servidor es Node.js , que se ha demostrado que puede manejar 1 millón de conexiones simultáneas con hardware modesto, mientras que un servidor de Java / Tomcat lucharía por unos pocos miles.     

Los eventos también se usan mucho en la programación de red (p. ej., Nginx) para evitar los costosos bucles de espera ocupados y, en cambio, proporcionan una interfaz limpia para saber exactamente cuando una determinada operación está disponible (E / S, urgente datos etc). Esta es también una solución para el problema de C10k .

La idea básica es proporcionar al sistema operativo un conjunto de sockets (es decir, conexiones de red) para monitorear eventos, todos ellos o solo algunos en los que esté particularmente interesado (datos disponibles para leer, por ejemplo); cuando el sistema operativo detecte dicha actividad en uno de los sockets de la lista, recibirá una notificación del evento que estaba buscando mediante la API, que luego deberá determinar de dónde proviene y actuar en consecuencia. .

Ahora, esta es una vista abstracta y de bajo nivel, además de difícil de escalar bien. Sin embargo, hay bastantes marcos de trabajo de nivel superior que se ocupan de eso de forma multiplataforma: Twisted for Python, Boost.Asio for C ++ o libevent for C vienen a mi mente.

Los sistemas integrados casi siempre son inherentemente controlados por eventos, incluso si no están programados explícitamente como tales.

Estos eventos provienen de interrupciones de hardware, pulsaciones de botones, lecturas de tiempo analógico a digital, caducidad del temporizador, etc.

Los sistemas embebidos de baja potencia son incluso más propensos a ser impulsados por eventos; pasan la mayor parte de su tiempo durmiendo (CPU durmiendo en un modo de bajo consumo de energía), esperando que algo suceda (ese "algo" es un evento).

Uno de los marcos más comunes y populares para sistemas integrados controlados por eventos es el Quantum Platform (QP) (el QP también funciona bajo Linux, Windows y cualquier sistema operativo similar a Unix.) Las máquinas de estado son un ajuste natural para la programación dirigida por eventos, ya que el programa no es "secuencial" en el sentido típico, sino que es un conjunto de "devoluciones de llamada" que se invocan según el estado del sistema y el evento actual.

Mensajes de eventos Gregor Hohpe.

Arquitecturas dirigidas por eventos Gregor Hohpe.

arquitectura SEDA , Gales, Culler, Brewer.

  

¿cómo se maneja en la programación normal de back-end cuando sucede algo? ¿Otra cosa?

Finite State Machine es un enfoque común

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

En los sistemas integrados, los eventos ocurren durante las interrupciones. Hay muchas fuentes de interrupciones, desde los temporizadores hasta la E / S.

También, RTOS puede tener eventos también. Un ejemplo es esperar un mensaje de otra tarea.

Para el sistema no integrado, pero algo que estaba haciendo en C # era el sistema SCADA. Hubo muchos eventos vinculados a lo que estaba sucediendo en el almacén cuando la carga se descargó parte del evento generado por el sistema y otra parte estaba escribiendo un nuevo estado en la base de datos. Por supuesto, teníamos algún cliente GUI pero era solo para mostrar el estado de la base de datos que reflejaba el estado del almacén. Así que era un software de servidor backend basado en eventos y subprocesos. Muy difícil de desarrollar.

enlace