Patrón de diseño Observer

 Observador (en inglés: Observer) es un patrón de diseño de software que define una dependencia del tipo uno a muchos entre objetos, de manera que cuando uno de los objetos cambia su estado, notifica este cambio a todos los dependientes.

Patrón de diseño basado en eventos

La arquitectura dirigida por eventos es un tipo de arquitectura software que se basa en la producción, detención y procesamiento de eventos y, si se considera oportuno, la reacción ante ellos. En la mayoría de los casos, el dispositivo que genera un evento no es el mismo que el que lo recibe y procesa.

Esta arquitectura está compuesta por productores y consumidores de eventos. El primero detecta los eventos y los representa como mensajes. No conoce al consumidor del evento ni el resultado que generará este último.

Una vez que se detecta un evento, este se transmite del productor a los consumidores a través de canales de eventos, donde se procesa de manera asíncrona con una plataforma para este fin. Cuando se produce un evento, se debe informar a los consumidores, quienes podrían procesarlo o simplemente recibirlo.

Procesamientos de eventos

Una arquitectura de este tipo puede se puede procesar 2 formas:

• Publicación/suscripción-->la infraestructura de mensajería mantiene el seguimiento de las suscripciones. Cuando se publica un evento, se envía el evento a cada suscriptor. Después de que se recibe un evento, no se puede reproducir, y los nuevos suscriptores no ven el evento. (Rabbit)
• Flujo de eventos-->los eventos se escriben en un registro. Los eventos siguen un orden estricto (dentro de una partición) y son duraderos. Los clientes no se suscriben al flujo, sino que un cliente puede leer desde cualquiera de sus partes. El cliente es responsable de avanzar su posición en el flujo. Esto significa que un cliente puede unirse en cualquier momento y puede reproducir los eventos. (Kakfka). Hay varios tipos de flujo de eventos:
  • El procesamiento de flujos de eventos utiliza una plataforma de transmisión de datos, como Apache Kafka, para incorporar los eventos y procesar o transformar su flujo. Este procesamiento se puede utilizar para detectar patrones significativos en los flujos.
  • El procesamiento de eventos simple surge cuando un evento desencadena inmediatamente una acción en el consumidor.
  • El procesamiento de eventos complejo requiere que un consumidor de eventos procese una serie de ellos para detectar patrones.

Estructura del evento
Un evento puede estar hecho de dos partes, el encabezado evento y el cuerpo evento. El encabezado de evento puede incluir información como el nombre del evento, fecha y hora para el evento, y el tipo de evento. El texto del evento es la parte que describe lo que ha ocurrido en realidad.

Capas del flujo del evento
Una arquitectura de evento disparado se basa en cuatro capas lógicas:

1. Generador evento
2. Canal de evento
3. Motor de procesamiento de eventos
4. Actividad de descarga dirigida por evento

Diferencias entre patrón DAO y Repository

 Una de las principales diferencias entre DAO y Repository se halla en el nivel en el que se ubican. El primero se ubica en un nivel mas bajo, mucho mas cerca a la fuente de datos, mientras que el segundo se ubica al mismo nivel de la capa de modelo de dominio, un poco más arriba que el primero.

Patrón de diseño repositorio

Patrón de diseño DAO

 DAO es el patrón mas usado para realizar la persistencia de los objetos de dominio, la forma mas común y básica de este patron es una clase que contiene las operaciones CRUD (Create, Read, Update, Delete).

Este patrón nos permite separar la lógica del negocio con respecto a la lógica de persistencia, de esta forma se pueden crear variedad de implementaciones de persistencia (usando ORM o ADO.Net) sin que lleguen a afectar al dominio. El problema es que mayormente este patrón no tiene una responsabilidad bien definida y muchos lo toman como una pasarela para hablar con la base de datos, creando un método para cada posible consulta que se realice o por cada actualización parcial