Convalida lato client (convalida nei livelli di presentazione)
Suggerimento
Questo contenuto è un estratto dell'eBook, Architettura di microservizi .NET per applicazioni .NET in contenitori, disponibile in documentazione .NET o come PDF scaricabile gratuito che può essere letto offline.
Anche quando l'origine della verità è il modello di dominio e in definitiva è necessario disporre della convalida a livello di modello di dominio, la convalida può comunque essere gestita sia a livello di modello di dominio (lato server) che all'interfaccia utente (lato client).
La convalida lato client è un'ottima comodità per gli utenti. Consente di risparmiare tempo che altrimenti trascorrerebbero in attesa di una risposta dal server che potrebbe restituire errori di convalida. In termini aziendali, anche poche frazioni di secondi moltiplicato centinaia di volte ogni giorno si sommano a un sacco di tempo, spese e frustrazioni. La convalida immediata e semplice consente agli utenti di lavorare in modo più efficiente e produrre un input e un output di qualità migliori.
Proprio come il modello di visualizzazione e il modello di dominio sono diversi, la convalida del modello di visualizzazione e la convalida del modello di dominio possono essere simili, ma servono uno scopo diverso. Se si è preoccupati riguardo al principio DRY (Don't Repeat Yourself), considerare che in questo caso il riutilizzo del codice potrebbe anche significare accoppiamento, e nelle applicazioni aziendali è più importante evitare di accoppiare il lato server al lato client che seguire il principio DRY.
Anche quando si usa la convalida lato client, è consigliabile convalidare sempre i comandi o gli oggetti DTO di input nel codice del server, perché le API del server sono un possibile vettore di attacco. In genere, eseguire entrambe le operazioni è la scelta migliore perché, se si dispone di un'applicazione client, dal punto di vista dell'esperienza utente, è consigliabile essere proattivi e non consentire all'utente di immettere informazioni non valide.
Pertanto, nel codice lato client in genere si convalidano i ViewModel. È anche possibile convalidare i DTO o i comandi di output client prima di inviarli ai servizi.
L'implementazione della convalida lato client dipende dal tipo di applicazione client che si sta creando. Sarà diverso se si convalidano i dati in un'applicazione Web MVC con la maggior parte del codice in .NET rispetto a un'applicazione Web a pagina singola con il codice di convalida in JavaScript o TypeScript.
Risorse aggiuntive
Convalida nelle app core di ASP.NET
- Rick Anderson. Aggiunta della convalida
https://learn.microsoft.com/aspnet/core/tutorials/first-mvc-app/validation
Convalida nelle app Web SPA (Angular 2, TypeScript, JavaScript, Blazor WebAssembly)
convalida modulo
https://angular.io/guide/form-validationConvalida. Documentazione di Breeze.
https://breeze.github.io/doc-js/validation.htmlASP.NET Core Blazor moduli e componenti di input \ </aspnet/core/blazor/forms-and-input-components>
In sintesi, questi sono i concetti più importanti per quanto riguarda la convalida:
Le entità e le aggregazioni devono applicare la propria coerenza e essere "sempre valide". Le radici di aggregazione sono responsabili della coerenza tra più entità all'interno della stessa aggregazione.
Se si ritiene che un'entità debba immettere uno stato non valido, è consigliabile usare un modello a oggetti diverso, ad esempio usando un DTO temporaneo fino a quando non si crea l'entità di dominio finale.
Se è necessario creare diversi oggetti correlati, ad esempio un'aggregazione, e sono validi solo una volta creati tutti questi oggetti, è consigliabile usare il modello Factory.
Nella maggior parte dei casi, la convalida ridondante sul lato client è utile, perché l'applicazione può essere proattiva.
