I validatori duplicano la logica aziendale?

Question

So che è possibile utilizzare i validatori per controllare l'immissione dei dati nel livello di presentazione di un'applicazione (ad es. regex, campi obbligatori ecc.) e per mostrare un messaggio e / o un'icona marcatore richiesta. La convalida dei dati appartiene generalmente al livello aziendale. Come evitare di mantenere due serie di convalide sui dati che sto raccogliendo?

MODIFICA: So che la convalida della presentazione è buona e che informa l'utente e che non è infallibile. Resta il fatto, no, che sto controllando efficacemente la stessa cosa in due punti?

Answer 1

Sì e no.

Dipende dall'architettura dell'applicazione. Supponiamo che tu stia creando un'applicazione di livello n, poiché la stragrande maggioranza delle applicazioni oggigiorno tende a seguire quel modello.

La convalida nell'interfaccia utente è progettata per fornire un feedback immediato all'utente finale del sistema per impedire che la funzionalità nei livelli inferiori venga mai eseguita in primo luogo con input non validi. Ad esempio, non vorrai nemmeno provare a contattare il server Active Directory senza un nome utente e una password per tentare l'autenticazione. La convalida a questo punto consente di risparmiare tempo di elaborazione necessario per creare un'istanza di un oggetto, configurarlo e fare un viaggio di andata e ritorno non necessario al server per apprendere qualcosa che si potrebbe facilmente dire attraverso una semplice ispezione dei dati.

La convalida nelle librerie di classe è un'altra storia. Qui, stai convalidando regole aziendali . Mentre si può sostenere che la convalida nell'interfaccia utente e la convalida nelle librerie di classi sono le stesse, io tenderei a non essere d'accordo. La convalida delle regole di business tende ad essere molto più complessa. Le tue regole in questo caso potrebbero essere più sfumate e potrebbero rilevare cose che non possono essere raccolte attraverso l'interfaccia utente. Ad esempio, è possibile applicare una regola che stabilisce che l'utente può eseguire un metodo solo dopo che tutte le proprietà di una classe sono state inizializzate correttamente e solo se l'utente è membro di un gruppo di utenti specifico. In alternativa, è possibile specificare che un oggetto può essere modificato solo se non è stato modificato nelle ultime ventiquattro ore. In alternativa, è possibile specificare semplicemente che un valore di stringa non può essere nullo o vuoto.

Nella mia mente, tuttavia, un software progettato correttamente utilizza un meccanismo comune per imporre DRY (se possibile) sia dall'interfaccia utente che dalla libreria di classi. Nella maggior parte dei casi, è possibile. (In molti casi, il codice è così banale, non ne vale la pena.)

Answer 2

Non credo che la validazione lato client (livello di presentazione) sia effettiva, validazione utile; piuttosto, avvisa semplicemente l'utente di eventuali errori rilevati dalla convalida sul lato server (livello aziendale). Lo considero un componente dell'interfaccia utente piuttosto che un'utilità di convalida effettiva e, in quanto tale, non penso che entrambi abbiano violato DRY.

EDIT: Sì, stai facendo la stessa azione, ma per motivi completamente diversi. Se il tuo unico obiettivo è l'adesione rigorosa a DRY, non vuoi fare entrambe le cose. Tuttavia, eseguendo entrambe le operazioni, mentre è possibile che si stia eseguendo la stessa azione, i risultati di tale azione vengono utilizzati per scopi diversi (convalida effettivamente le informazioni rispetto alla notifica all'utente di un problema) e, pertanto, l'esecuzione della stessa azione due volte risulta effettivamente ogni volta in informazioni utili.

Answer 3

Penso che avere buone validazioni a livello di applicazione consenta molteplici vantaggi. 1. Facilita i test unitari 2. Puoi aggiungere più client senza preoccuparti della coerenza dei dati.

La convalida dell'interfaccia utente può essere utilizzata come strumento per fornire tempi di risposta rapidi agli utenti finali.

Answer 4

Ogni livello di convalida ha uno scopo diverso. La convalida dell'interfaccia utente viene utilizzata per scartare l'input errato. La convalida della logica aziendale viene utilizzata per eseguire la convalida in base alle regole aziendali.

Per la convalida dell'interfaccia utente è possibile utilizzare RequiredFieldValidators e altri validatori disponibili nel framework ASP.NET. Per la convalida aziendale è possibile creare un motore di convalida che convalida l'oggetto. Ciò può essere realizzato utilizzando gli attributi personalizzati.

Ecco un articolo che spiega come creare un framework di validazione usando attributi personalizzati:

http://highoncoding.com/Articles/424_Creating_a_Domain_Object>Valid