-
Notifications
You must be signed in to change notification settings - Fork 2
Fase I Application Layer
Puede visualizar los commit de esta fase : Branch ApplicationLayer
En la capa de aplicación se destacan las solicitudes y consultas por medio de Command, CommandHandler, Query y QueryHandler, que necesita la aplicación para su presentación, además de validaciones de entrada para su respectiva funcionalidades, todo esto con una libreria que nos permite tener una cominicacion sin dependencia entre ellas MediatR.
Es una Librería que nos permite desacoplar el envió, respuesta y notificación de la mensajería esto lo hace al desacoplar el envió de mensajes en el proceso desde el manejo de mensaje.
En nuestro caso se va a utilizar para realizar la comunicación entre:
- Command ---> CommandHandler
- Query ---> QueryHandler
MediatR tiene dos tipos de mensajes que distribuye:
- Mensajes de solicitud / respuesta, enviados a un solo manejador (Vamos a trabajar por el momento)
- Mensajes de notificación enviados a múltiples controladores
Para realizar la implementación Primero, crea un mensaje
La interfaz IRequest comprende un argumento, la cual es lo esperado.
using MediatR; //----------------------------------------------- Libreria
namespace Item.Application.Commands
{
public class CreateCommand : IRequest<bool> //- La interfaz solicitud/respuesta maneja el comando como las consultas.
{
public string Number { get; set; }
...
}
}
Luego, creamos el controlador: La interfaz IRequestHandler comprende dos argumentos, el primero es lo que el esta esperando y la segundo, la respuesta que se va a enviar.
using MediatR; //----------------------------------------------- Libreria
namespace Item.Application.Commands
{
public class CreateCommandHandler : IRequestHandler<CreateCommand, bool> //- La interfaz a implementar para comandos y consultas.
{
public async Task<bool> Handle(CreateCommand request, CancellationToken cancellationToken)
{
return true;
}
}
}
Básicamente, la clase de comando contiene todos los datos que se necesitan para llevar a cabo una transacción empresarial mediante los objetos de modelo de dominio. Por tanto, los comandos son simplemente las estructuras de datos que contienen datos de solo lectura y ningún comportamiento.
Un controlador de comandos recibe un comando y obtiene un resultado del agregado que se usa (de dominio). la ejecucion de la misma debe de afectar el estado de sistema.
-
Normalmente, el controlador de comandos realiza estos pasos:
- Recibe el objeto de comando, como un DTO (desde el mediador u otro objeto de infraestructura).
- Valida que el comando sea válido (si no lo hace el mediador).
- Crea una instancia de la instancia de raíz agregada que es el destino del comando actual.
- Ejecuta el método en la instancia de raíz agregada y obtiene los datos necesarios del comando.
- Conserva el nuevo estado del agregado en su base de datos relacionada. Esta última operación es la transacción real.
La clase de consultas contiene todos los datos que se necesitan para llevar a cabo las series de filtros o condiciones necesarias para la consulta empresarial mediante los objetos de modelo de dominio. Por tanto, las consultas son simplemente las estructuras de datos que contienen datos de solo lectura y ningún comportamiento.
Un controlador de consulta recibe una consulta y obtiene un resultado del agregado que se usa (de dominio). en este caso el estado del sistema no debe ser afectado ya que simplemente estamos realizando consultas a nuestro persistencia.
Estan comprendidos por los DTO se implementa como una puerta de enlace para realizar el mapeo de la entidades con la capa de dominio y ViewModel el cuel es responsable de implementar el comportamiento de la vista para responder a las acciones del usuario y de exponer los datos del modelo de forma tal que sea fácil usar bindings en la vista.
Autor: Johan Villegas - Ingeniero de Sistemas