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.

Baixar PDF

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 de aplicativos móveis Xamarin

• Validar entrada de texto e mostrar erros
  https://developer.xamarin.com/recipes/ios/standard_controls/text_field/validate_input/

• Chamada de retorno de validação
  https://developer.xamarin.com/samples/xamarin-forms/XAML/ValidationCallback/

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-validation

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

• Componentes 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.

AnteriorAvançar