Fala aí, pessoal! Tudo certo? Em nosso último artigo, aprendemos de maneira bem simples e prática como implementar a biblioteca Mediatr, um Pattern muito útil quando se diz em desacoplamento e menos referência explícita entre objetos.
Para complementar, iremos aprender a validar os campos dos request’s de forma muito simples utilizando uma biblioteca muito bacana chamada FluentValidator.
Configuração inicial
Para começarmos a validar os campos dos nossos Request’s, precisamos instalar o pacote FluentValidator.Core em nosso projeto Domain.
Install-Package FluentValidator.Core
Agora que temos o FluentValidator instalado em nosso projeto, iremos iniciar a codificação / validação dos nossos campos. Para isso, iremos fazer algumas pequenas modificações em nossa classe Product que criamos em nosso artigo anterior.
<script src=“https://gist.github.com/miltoncamara/32b0eed6621eaed30b62d69dda2c9ecd.js"></ script>
Notem como ficou a classe Product, após as alterações. Se vocês perceberem, estamos herdando uma classe base EntityBase e agora a interface IRequest recebe como retorno o tipo Response. Percebam que a mágica começa no construtor desta classe onde instanciamos um objeto do tipo ValidationContract(this). É nesta classe que se encontram alguns métodos de validação como IsRequired, IsNotNull, IsNotEmpty, IsGreaterThan etc.
<script src=“https://gist.github.com/miltoncamara/8165c575d4cd23de179a8b8b54b126c0.js"></ script>
Percebam na classe acima, temos somente o campo Id, como a ideia é exemplificar. Mantive somente este campo, mas podemos utilizar nesta classe base outros campos em comum como Data de Criação, Ativo, Status, etc, porém o mais importante desta classe é a herança que temos do tipo Notifiable, que é responsável por armazenar todas as notificações de validação dos nossos modelos.
<script src=“https://gist.github.com/miltoncamara/ee8324068ba1416a01f6bd4a4ebb2d01.js”></ script>
A classe Response é responsável por todos os retornos da nossa aplicação, centralizando e padronizando a mensagem. Notem que deixamos a variável Data com o tipo object, dessa forma, a classe fica totalmente flexível com os retornos. Podendo entregar uma lista complexa, como uma simples string.
Agora que refatoramos nossa classe Product e criamos a validação em cima dos campos existentes, iremos efetuar algumas alterações em nosso Handler, classe responsável por executar o fluxo do nosso Request.
<script src=“https://gist.github.com/miltoncamara/95a5ab14a69de11e30526c0285722c92.js"></ script>
Notem, agora, que após a refatoração da classe ProductHandler. Removemos a validação dentro do método Handler, deixando a responsabilidade somente de salvar o produto no repositório.
Uma característica bastante interessante do MediatR, é a possibilidade de criar uma extensão do seu Pipeline, ou seja, posso executar algum procedimento antes ou depois da execução do Handler principal, sendo assim, iremos criar uma classe ValidationPipeline, onde iremos verificar se os Request’s enviados estão válidos e não existem mensagens de notificação.
<script src=“https://gist.github.com/miltonca mara/1a8113f97fc267d1d4f1dbcbc75e50be.js"></script>
Como vocês podem ver na classe acima, implementamos a interface IValidationBehavior, ou seja, antes do Handler principal ser executado, o fluxo da aplicação será direcionado para o método Handler (ValidationPipeline), onde temos como parâmetro o request (classe ou dto onde passo os parâmetros do request) e o next que é o método do Handler principal, sendo assim, podemos criar procedimentos e depois invocar o método next. Em nosso caso, estou verificando se o parâmetro request é válido (IsValid). Em caso negativo, interrompemos o fluxo da aplicação e criamos o response com as notificações de erro e informando o parâmetro HasError como true.
“Um detalhe super importante é que não podemos esquecer de registrar essa classe em nosso container de injeção de dependência na classe Startup.cs (Linha 37).”
Efetuando um Request com o campo Price 0, temos como retorno uma mensagem de erro: “Valor deve ser maior do que zero.
Efetuando um Request com todos os campos válidos, o retorno é uma mensagem que o produto foi inserido com sucesso.
A validação dos modelos em nosso backend pode ser feito na especificação do mesmo, ou seja, não preciso mais criar aquele tanto de IF no Handler principal “sujando” então o método que tem como responsabilidade organizar o fluxo do comando e não validar campos, agora cada parte do código tem responsabilidades bem específicas seguindo então a primeira letra do SOLID, SRP ou, Princípio da Responsabilidade Única.
Espero que gostem do artigo e se tiverem alguma dúvida, deixe seu comentário abaixo!
Link do projeto: https://github.com/miltoncamara/mediatr-netcore-sample
Referências:
De 0 a 10, o quanto você recomendaria este artigo para um amigo?