Validação do lado do cliente (validação nas camadas de apresentação)
Dica
Esse conteúdo é um trecho do eBook da Arquitetura de Microsserviços do .NET para os Aplicativos .NET em Contêineres, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.
Mesmo quando a fonte de verdade for o modelo de domínio e, em último caso, você precisar ter validação no nível de modelo de domínio, a validação ainda poderá ser manipulada tanto no nível de modelo de domínio (lado do servidor) quanto da interface do usuário (lado do cliente).
A validação do lado do cliente é uma ótima conveniência para usuários. Ela economiza tempo que de outra forma seria gasto aguardando uma viagem de ida e volta que talvez retorne erros de validação. Em termos de negócios, até mesmo algumas frações de segundos multiplicadas por centenas de vezes por dia chega a ser muito tempo, despesa e frustração. A validação imediata e simples permite que os usuários trabalhem com mais eficiência e façam contribuições e produzam entradas e saídas de melhor qualidade.
Como o modelo de exibição e o modelo de domínio são diferentes, a validação do modelo de exibição e do modelo de domínio podem ser semelhantes, mas têm um propósito diferente. Se você se preocupa com DRY (o princípio Don't Repeat Yourself), considere que neste caso a reutilização do código também pode significar acoplamento, e em aplicações empresariais é mais importante não acoplar 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, porque as APIs do servidor são um possível vetor de ataque. Geralmente, fazer as duas é a melhor opção, porque se você tiver um aplicativo cliente, de uma perspectiva do UX, será 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 ou comandos de saída do cliente antes de enviá-los aos serviços.
A implementação de validação do lado do cliente depende de qual tipo de aplicativo cliente você está criando. Será diferente se você estiver validando dados em um aplicativo Web MVC da Web com a maior parte do código em .NET, um aplicativo Web SPA com a validação sendo codificada em JavaScript ou TypeScript ou um aplicativo móvel codificado com Xamarin e C#.
Recursos adicionais
Validação em aplicativos ASP.NET Core
- Rick Anderson. Adicionando uma 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-validationValidação. Documentação da Breeze.
https://breeze.github.io/doc-js/validation.htmlComponentes de entrada formulários Blazor ASP.NET Core \ </aspnet/core/blazor/forms-and-input-components>
Em resumo, estes são os conceitos mais importantes no que diz respeito à validação:
Entidades e agregações devem impor sua própria consistência e serem “sempre válidas". 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 entrar em 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 definitiva.
Se precisar criar vários objetos relacionados, como uma agregação, e eles apenas forem válidos depois que todos tiverem sido criados, considere usar o padrão de fábrica.
Na maioria dos casos, ter validação redundante no lado do cliente é bom, porque o aplicativo pode ser proativo.
