Validação IA

Fundamentos: Clean Architecture com Mediator

Descrição: Implementação prática de Clean Architecture utilizando MediatR, mostrando como integrar o padrão Mediator em aplicações .NET com CQRS.

📦 Passo 1: Instalando o MediatR

1.1 Instalação no projeto Application

# Navegar até o projeto Application
cd Aviator.Application

# Instalar o pacote MediatR via dotnet CLI
dotnet add package MediatR

# Ou via Package Manager Console
Install-Package MediatR

Versão recomendada: MediatR 12.x (mais recente estável)

1.2 O que o MediatR traz?

Padrão Mediator implementado
Desacoplamento completo entre emissores e handlers
Pipeline behaviors para cross-cutting concerns
Pub/Sub para eventos
Descoberta automática de handlers

🔄 Passo 2: Refatorando o Caso de Uso Create

2.1 Refatorando o Response

ANTES (sem Mediator):

// Aviator.Application/Planes/UseCases/Create/Response.cs
using Aviator.Application.Shared.UseCases.Abstractions;

namespace Aviator.Application.Planes.UseCases.Create;

// Implementava IResponse (nossa interface)
public record Response(string Message) : IResponse;

DEPOIS (com Mediator):

// Aviator.Application/Planes/UseCases/Create/Response.cs
namespace Aviator.Application.Planes.UseCases.Create;

// Agora é um simples record, não implementa nada
// O MediatR não exige interfaces específicas para Responses
public record Response(string Message);

// Explicação: O MediatR trabalha com qualquer tipo como Response
// Não precisa de interfaces marcadoras

2.2 Refatorando o Command

ANTES (sem Mediator):

// Aviator.Application/Planes/UseCases/Create/Command.cs
using Aviator.Application.Shared.UseCases.Abstractions;

namespace Aviator.Application.Planes.UseCases.Create;

// Implementava nossa interface ICommand
public record Command(string Name) : ICommand;

DEPOIS (com Mediator):

// Aviator.Application/Planes/UseCases/Create/Command.cs
using MediatR;  // Nova referência

namespace Aviator.Application.Planes.UseCases.Create;

// Agora implementa IRequest<TResponse> do MediatR
// IRequest<Response> = "Eu sou um request que retorna um Response"
public record Command(string Name) : IRequest<Response>;

// Explicação:
// IRequest<T> = interface do MediatR para commands/queries
// O generic <Response> especifica o tipo de retorno

2.3 Refatorando o Handler

ANTES (sem Mediator):

// Aviator.Application/Planes/UseCases/Create/Handler.cs
using Aviator.Application.Shared.UseCases.Abstractions;

namespace Aviator.Application.Planes.UseCases.Create;

// Implementava nossa interface IHandler
public class Handler : IHandler<Command, Response>
{
    // Nosso método personalizado
    public async Task<Response> HandleAsync(Command command)
    {
        await Task.Delay(10);
        return new Response("Plane Created");
    }
}

DEPOIS (com Mediator):

// Aviator.Application/Planes/UseCases/Create/Handler.cs
using MediatR;  // Nova referência

namespace Aviator.Application.Planes.UseCases.Create;

// Agora implementa IRequestHandler<TRequest, TResponse>
public class Handler : IRequestHandler<Command, Response>
{
    // Método padrão do MediatR (não é Async no nome)
    public async Task<Response> Handle(
        Command request, 
        CancellationToken cancellationToken = default)
    {
        // cancellationToken é importante para operações assíncronas
        // Permite cancelar a operação se o cliente desconectar
        
        await Task.Delay(10, cancellationToken); // Passa o cancellationToken
        
        return new Response("Plane Created");
    }
}

// Diferenças importantes:
// 1. Método chama-se Handle (não HandleAsync)
// 2. Recebe CancellationToken (boas práticas de async)
// 3. Implementa IRequestHandler (interface do MediatR)

🏗️ Passo 3: Configurando a Injeção de Dependência

3.1 Criando a classe de configuração

Local: Aviator.Application/DependencyInjection.cs

using Microsoft.Extensions.DependencyInjection;

namespace Aviator.Application;

// Classe estática para métodos de extensão
public static class DependencyInjection
{
    // Método de extensão para IServiceCollection
    // "this IServiceCollection" permite chamar como services.AddApplication()
    public static IServiceCollection AddApplication(this IServiceCollection services)
    {
        // Configura o MediatR
        services.AddMediatR(configuration =>
        {
            // Diz ao MediatR para buscar handlers neste Assembly
            // typeof(DependencyInjection).Assembly = Assembly atual (Application)
            configuration.RegisterServicesFromAssembly(typeof(DependencyInjection).Assembly);
        });
        
        return services; // Permite method chaining
    }
}

// O que acontece aqui:
// 1. MediatR scaneia o Assembly da Application
// 2. Encontra todas as classes que implementam IRequestHandler<,>
// 3. Registra automaticamente no container DI
// 4. Cria o mapeamento Command → Handler

3.2 Como o MediatR encontra os handlers?

O MediatR usa reflection para:

Listar todos os tipos no Assembly
Filtrar os que implementam IRequestHandler<TRequest, TResponse>
Extrair o TRequest (Command/Query) de cada handler
Criar um dicionário interno: CommandType → HandlerType

Exemplo do mapeamento interno:

Command (CreatePlaneCommand) → Handler (CreatePlaneHandler)
Command (UpdatePlaneCommand) → Handler (UpdatePlaneHandler)
Query (GetPlaneQuery) → Handler (GetPlaneHandler)

🌐 Passo 4: Refatorando a API

4.1 Refatorando o Program.cs

ANTES (sem Mediator):

// Aviator.Api/Program.cs
using AviatorHandler = Aviator.Application.Planes.UseCases.Create.Handler;
using CreatePlaneCommand = Aviator.Application.Planes.UseCases.Create.Command;

var builder = WebApplication.CreateBuilder(args);

// Registro manual do Handler
builder.Services.AddTransient<AviatorHandler>();

var app = builder.Build();

// Endpoint acoplado ao Handler específico
app.MapPost("/v1/planes", async (AviatorHandler handler, CreatePlaneCommand command) 
    => await handler.HandleAsync(command));

app.Run();

DEPOIS (com Mediator):

// Aviator.Api/Program.cs
using Aviator.Application;  // Para AddApplication()
using CreatePlaneCommand = Aviator.Application.Planes.UseCases.Create.Command;

var builder = WebApplication.CreateBuilder(args);

// Configura toda a aplicação de uma vez
// Isso registra automaticamente TODOS os handlers
builder.Services.AddApplication();

var app = builder.Build();

// Endpoint desacoplado - conhece apenas ISender
// ISender = interface para enviar commands/queries
app.MapPost("/v1/planes", async (ISender sender, CreatePlaneCommand command) 
    => await sender.Send(command));

app.Run();

// O que mudou:
// 1. Não registra handlers manualmente
// 2. Usa ISender (abstração do MediatR)
// 3. Chama Send() em vez de HandleAsync()
// 4. Não conhece o Handler específico

4.2 Explicando ISender e o fluxo:

Cliente (HTTP) → Endpoint → ISender.Send(command) → MediatR → Handler correto → Response
                     ↑                                    ↑
              Não sabe qual handler           Encontra handler automaticamente

Vantagem: Se amanhã mudarmos o Handler, o Endpoint não precisa ser alterado.

🧪 Passo 5: Testando a Implementação

5.1 Executando a aplicação:

# Na pasta Aviator.Api
dotnet run

# Saída esperada:
# Now listening on: http://localhost:5070
# Application started. Press Ctrl+C to shut down.

5.2 Testando com Postman:

Requisição POST:

POST http://localhost:5070/v1/planes
Content-Type: application/json

{
    "name": "Cessna 172"
}

Resposta esperada:

{
    "message": "Plane Created"
}

5.3 Verificando o que foi registrado:

// Para debug, você pode verificar no Startup
var serviceProvider = builder.Services.BuildServiceProvider();
var sender = serviceProvider.GetService<ISender>();
// sender contém todos os mapeamentos Command→Handler

🔍 Passo 6: Entendendo o Funcionamento Interno

6.1 Como o MediatR resolve qual handler usar?

// Internamente, o MediatR faz algo como:
public class Mediator : ISender
{
    private readonly Dictionary<Type, Type> _handlerMappings;
    
    public async Task<TResponse> Send<TResponse>(IRequest<TResponse> request)
    {
        // 1. Obtém o tipo do request (ex: CreatePlaneCommand)
        var requestType = request.GetType();
        
        // 2. Busca no mapeamento qual handler corresponde
        var handlerType = _handlerMappings[requestType];
        
        // 3. Resolve o handler do container DI
        var handler = _serviceProvider.GetService(handlerType);
        
        // 4. Chama o método Handle
        return await ((dynamic)handler).Handle((dynamic)request, cancellationToken);
    }
}

6.2 Mapeamento Automático vs Manual:

Com MediatR (Automático):

// MediatR descobre sozinho
services.AddMediatR(cfg => 
    cfg.RegisterServicesFromAssembly(Assembly.GetExecutingAssembly()));

Sem MediatR (Manual):

// Você registra cada handler manualmente
services.AddTransient<CreatePlaneHandler>();
services.AddTransient<UpdatePlaneHandler>();
services.AddTransient<DeletePlaneHandler>();
services.AddTransient<GetPlaneHandler>();
// ... e assim para cada handler no sistema

⚖️ Análise Crítica: Vale a Pena Usar Mediator?

Quando VALE A PENA usar MediatR:

1. Pipeline Behaviors (Middleware)

// Exemplo: Logging automático para todos os handlers
public class LoggingBehavior<TRequest, TResponse> 
    : IPipelineBehavior<TRequest, TResponse>
{
    public async Task<TResponse> Handle(
        TRequest request,
        RequestHandlerDelegate<TResponse> next,
        CancellationToken cancellationToken)
    {
        // Log antes
        Console.WriteLine($"Handling {typeof(TRequest).Name}");
        
        var response = await next();
        
        // Log depois
        Console.WriteLine($"Handled {typeof(TRequest).Name}");
        
        return response;
    }
}

// Registro (uma vez, vale para todos handlers)
services.AddTransient(typeof(IPipelineBehavior<,>), typeof(LoggingBehavior<,>));

2. Validação Centralizada

// Validação automática para todos os requests
public class ValidationBehavior<TRequest, TResponse> 
    : IPipelineBehavior<TRequest, TResponse>
    where TRequest : IValidatable
{
    // Valida TUDO automaticamente
}

3. Eventos (Pub/Sub)

// Múltiplos handlers para um evento
public class PlaneCreatedEvent : INotification
{
    public int PlaneId { get; set; }
}

public class SendEmailHandler : INotificationHandler<PlaneCreatedEvent>
{
    public Task Handle(PlaneCreatedEvent notification, CancellationToken ct)
    {
        // Envia email
    }
}

public class UpdateAuditHandler : INotificationHandler<PlaneCreatedEvent>  
{
    public Task Handle(PlaneCreatedEvent notification, CancellationToken ct)
    {
        // Atualiza auditoria
    }
}

// Ambos são executados quando o evento é publicado

Quando NÃO VALE A PENA usar MediatR:

1. Projetos muito simples

// Se você tem apenas:
// - 5-10 handlers
// - Nenhum cross-cutting concern
// - Equipe pequena que conhece todo o código

// Overhead do MediatR > Benefícios

2. Performance crítica extrema

// Benchmarks mostram:
// - Handler direto: ~0.1ms
// - Com MediatR: ~0.3ms (3x mais lento)

// Para 99% dos casos, a diferença é insignificante
// Mas para sistemas que processam 100k req/segundo, importa

3. Dependências explícitas são obrigatórias

// Algumas arquiteturas exigem:
public class MyController
{
    // DEVE ver no construtor quais handlers usa
    public MyController(
        ICreatePlaneHandler createHandler,  // Explícito
        IUpdatePlaneHandler updateHandler)  // Explícito
    {
    }
}

// Com MediatR fica implícito:
public class MyController
{
    public MyController(ISender sender)  // Implícito - quais handlers?
    {
    }
}

📊 Comparação Detalhada

Aspecto

Sem Mediator

Com Mediator (MediatR)

Acoplamento

Alto (Endpoint→Handler)

Baixo (Endpoint→ISender)

Registro

Manual por handler

Automático por assembly

Cross-cutting

Em cada handler

Pipeline behaviors

Performance

Máxima

Pequeno overhead

Complexidade

Baixa

Média

Flexibilidade

Baixa

Alta

Testabilidade

Igual

Manutenção

Mais trabalho

Menos trabalho

🚀 Evoluindo a Implementação

Adicionando Pipeline Behaviors:

// Aviator.Application/DependencyInjection.cs (atualizado)
public static IServiceCollection AddApplication(this IServiceCollection services)
{
    services.AddMediatR(cfg =>
    {
        cfg.RegisterServicesFromAssembly(typeof(DependencyInjection).Assembly);
    });
    
    // Registra behaviors na ordem desejada
    services.AddTransient(typeof(IPipelineBehavior<,>), typeof(LoggingBehavior<,>));
    services.AddTransient(typeof(IPipelineBehavior<,>), typeof(ValidationBehavior<,>));
    services.AddTransient(typeof(IPipelineBehavior<,>), typeof(TransactionBehavior<,>));
    
    return services;
}

// Fluxo com behaviors:
// Request → Logging → Validation → Transaction → Handler → Response

Adicionando Validação com FluentValidation:

// Command com validação
public record Command(string Name) : IRequest<Response>, IValidatable;

// Behavior de validação
public class ValidationBehavior<TRequest, TResponse> 
    : IPipelineBehavior<TRequest, TResponse>
    where TRequest : IValidatable
{
    private readonly IEnumerable<IValidator<TRequest>> _validators;
    
    public async Task<TResponse> Handle(
        TRequest request,
        RequestHandlerDelegate<TResponse> next,
        CancellationToken cancellationToken)
    {
        if (_validators.Any())
        {
            var context = new ValidationContext<TRequest>(request);
            var results = await Task.WhenAll(
                _validators.Select(v => v.ValidateAsync(context, cancellationToken)));
            
            var failures = results.SelectMany(r => r.Errors).Where(f => f != null).ToList();
            
            if (failures.Count != 0)
                throw new ValidationException(failures);
        }
        
        return await next();
    }
}

🎯 Conclusão: Tomando a Decisão Correta

Use MediatR quando:

Sistema tem muitos handlers (> 20)
Precisa de cross-cutting concerns (logging, validation, caching)
Trabalha com eventos de domínio
Equipe grande com necessidade de desacoplamento
Projeto vai crescer significativamente

Não use MediatR quando:

Projeto é simples/pequeno
Performance é absolutamente crítica
Prefere simplicidade sobre flexibilidade
Dependências explícitas são requisito
Não vai usar features avançadas (behaviors, events)

Nossa implementação atual:

// Mudamos relativamente pouco:
// Command: ICommand → IRequest<Response>
// Handler: IHandler → IRequestHandler
// Endpoint: Handler direto → ISender
// Registro: Manual → Automático

// Benefícios obtidos:
// - Desacoplamento endpoint-handler
// - Preparado para behaviors
// - Escalabilidade futura

// Custo:
// - Biblioteca externa
// - Pequeno overhead
// - Curva de aprendizado

Recomendação final:

Comece sem MediatR para projetos simples. Quando perceber que precisa de:

Muitos handlers
Cross-cutting concerns repetitivos
Eventos de domínio
Desacoplamento forte

Então migre para MediatR. A migração é relativamente simples (como mostramos) e os benefícios valem a pena para sistemas em crescimento.

AnteriorPage 1

Atualizado há 12 dias

hashtagFundamentos: Clean Architecture com Mediator

hashtag📦 Passo 1: Instalando o MediatR

hashtag1.1 Instalação no projeto Application

hashtag1.2 O que o MediatR traz?

hashtag🔄 Passo 2: Refatorando o Caso de Uso Create

hashtag2.1 Refatorando o Response

hashtag2.2 Refatorando o Command

hashtag2.3 Refatorando o Handler

hashtag🏗️ Passo 3: Configurando a Injeção de Dependência

hashtag3.1 Criando a classe de configuração

hashtag3.2 Como o MediatR encontra os handlers?

hashtag🌐 Passo 4: Refatorando a API

hashtag4.1 Refatorando o Program.cs

hashtag4.2 Explicando ISender e o fluxo:

hashtag🧪 Passo 5: Testando a Implementação

hashtag5.1 Executando a aplicação:

hashtag5.2 Testando com Postman:

hashtag5.3 Verificando o que foi registrado:

hashtag🔍 Passo 6: Entendendo o Funcionamento Interno

hashtag6.1 Como o MediatR resolve qual handler usar?

hashtag6.2 Mapeamento Automático vs Manual:

hashtag⚖️ Análise Crítica: Vale a Pena Usar Mediator?

hashtagQuando VALE A PENA usar MediatR:

hashtagQuando NÃO VALE A PENA usar MediatR:

hashtag📊 Comparação Detalhada

hashtag🚀 Evoluindo a Implementação

hashtagAdicionando Pipeline Behaviors:

hashtagAdicionando Validação com FluentValidation:

hashtag🎯 Conclusão: Tomando a Decisão Correta

hashtagUse MediatR quando:

hashtagNão use MediatR quando:

hashtagNossa implementação atual:

hashtagRecomendação final:

Fundamentos: Clean Architecture com Mediator

📦 Passo 1: Instalando o MediatR

1.1 Instalação no projeto Application

1.2 O que o MediatR traz?

🔄 Passo 2: Refatorando o Caso de Uso Create

2.1 Refatorando o Response

2.2 Refatorando o Command

2.3 Refatorando o Handler

🏗️ Passo 3: Configurando a Injeção de Dependência

3.1 Criando a classe de configuração

3.2 Como o MediatR encontra os handlers?

🌐 Passo 4: Refatorando a API

4.1 Refatorando o Program.cs

4.2 Explicando ISender e o fluxo:

🧪 Passo 5: Testando a Implementação

5.1 Executando a aplicação:

5.2 Testando com Postman:

5.3 Verificando o que foi registrado:

🔍 Passo 6: Entendendo o Funcionamento Interno

6.1 Como o MediatR resolve qual handler usar?

6.2 Mapeamento Automático vs Manual:

⚖️ Análise Crítica: Vale a Pena Usar Mediator?

Quando VALE A PENA usar MediatR:

Quando NÃO VALE A PENA usar MediatR:

📊 Comparação Detalhada

🚀 Evoluindo a Implementação

Adicionando Pipeline Behaviors:

Adicionando Validação com FluentValidation:

🎯 Conclusão: Tomando a Decisão Correta

Use MediatR quando:

Não use MediatR quando:

Nossa implementação atual:

Recomendação final: