Validação do lado do cliente (validação nas camadas de apresentação)

Dica

Esse conteúdo é um trecho do eBook, arquitetura de microsserviços do .NET para aplicativos .NET em contêineres, disponível em do .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Baixar PDF

Mesmo quando a fonte da verdade é o modelo de domínio e, por fim, você deve ter validação no nível do modelo de domínio, a validação ainda pode ser tratada no nível do modelo de domínio (lado do servidor) e na interface do usuário (lado do cliente).

A validação do lado do cliente é uma ótima conveniência para os usuários. Economiza o tempo que seria gasto aguardando a ida e volta do servidor, que poderia retornar erros de validação. Em termos comerciais, mesmo algumas frações de segundo multiplicadas centenas de vezes por dia se acumulam em muito tempo, despesas e frustrações. A validação direta e imediata permite que os usuários trabalhem com mais eficiência e produzam entrada e saída de melhor qualidade.

Assim como o modelo de exibição e o modelo de domínio são diferentes, a validação do modelo de exibição e a validação do modelo de domínio podem ser semelhantes, mas servem a uma finalidade diferente. Se você estiver preocupado com DRY (o princípio Don't Repeat Yourself), considere que, nesse caso, a reutilização de código também pode significar acoplamento e, em aplicativos empresariais, é mais importante não associar o lado do servidor ao lado do cliente do que seguir o princípio DRY.

Mesmo ao usar a validação do lado do cliente, você sempre deve validar seus comandos ou DTOs de entrada no código do servidor, pois as APIs do servidor são um possível vetor de ataque. Normalmente, fazer ambos é a sua melhor aposta, pois se você tiver um aplicativo cliente, do ponto de vista da UX, é melhor ser proativo e não permitir que o usuário insira informações inválidas.

Portanto, no código do lado do cliente, você normalmente valida os ViewModels. Você também pode validar os DTOs de saída do cliente ou comandos antes de enviá-los para os serviços.

A implementação da validação do lado do cliente depende do tipo de aplicativo cliente que você está criando. Será diferente se você estiver validando dados em um aplicativo Web MVC com a maior parte do código no .NET versus um aplicativo Web SPA com o código de validação em JavaScript ou TypeScript.

Recursos adicionais

Validação em aplicativos do ASP.NET Core

• Rick Anderson. Adicionando validação
  https://learn.microsoft.com/aspnet/core/tutorials/first-mvc-app/validation

Validação em aplicativos Web SPA (Angular 2, TypeScript, JavaScript, Blazor WebAssembly)

• Validação de formulário
  https://angular.io/guide/form-validation

• Validação. Documentação do Breeze.
  https://breeze.github.io/doc-js/validation.html

• Formulários e componentes de entrada do ASP.NET Core Blazor \ </aspnet/core/blazor/forms-and-input-components>

Em resumo, esses são os conceitos mais importantes em relação à validação:

• Entidades e agregações devem impor sua própria consistência e ser "sempre válidas". As raízes agregadas são responsáveis pela consistência de várias entidades dentro da mesma agregação.

• Se você acha que uma entidade precisa inserir um estado inválido, considere usar um modelo de objeto diferente, por exemplo, usar um DTO temporário até criar a entidade de domínio final.

• Se você precisar criar vários objetos relacionados, como uma agregação, e eles só forem válidos depois que todos eles tiverem sido criados, considere usar o padrão Factory.

• Na maioria dos casos, ter validação redundante no lado do cliente é bom, pois o aplicativo pode ser proativo.

anterior próximo