Validação do lado do cliente (validação nas camadas de apresentação)
Gorjeta
Este conteúdo é um trecho do eBook, .NET Microservices Architecture for Containerized .NET Applications, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.
Mesmo quando a fonte da verdade é o modelo de domínio e, em última análise, você deve ter a 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 grande conveniência para os usuários. Isso economiza tempo que eles gastariam esperando por uma viagem de ida e volta ao servidor que poderia retornar erros de validação. Em termos de negócios, mesmo algumas frações de segundos multiplicadas centenas de vezes por dia somam muito tempo, despesas e frustração. A validação direta e imediata permite que os usuários trabalhem de forma mais eficiente e produzam entradas e saídas 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ê está preocupado com o DRY (o princípio de não se repetir), considere que, neste caso, a reutilização de código também pode significar acoplamento e, em aplicativos corporativos, é 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. Normalmente, fazer as duas coisas é a sua melhor aposta, porque se você tem 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 ou comandos de saída do cliente 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 da Web com a maior parte do código em .NET, um aplicativo Web SPA com essa 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 validação
https://learn.microsoft.com/aspnet/core/tutorials/first-mvc-app/validation
Validação em aplicações Web SPA (Angular 2, TypeScript, JavaScript, Blazor WebAssembly)
Validação do formulário
https://angular.io/guide/form-validationValidação. Documentação Breeze.
https://breeze.github.io/doc-js/validation.htmlASP.NET Formulários Core Blazor e componentes de entrada \ </aspnet/core/blazor/forms-and-input-components>
Em resumo, estes são os conceitos mais importantes no que diz respeito à validação:
As entidades e os agregados devem impor a sua própria coerência e ser «sempre válidos». As raízes agregadas são responsáveis pela consistência de várias entidades dentro do mesmo agregado.
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 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, porque o aplicativo pode ser proativo.
