Come evitare la doppia convalida dei dati in un'applicazione con interfaccia web?

Il nucleo non sa da dove vengono i dati, giusto? Quindi, dal momento che tutti gli input dei dati devono essere disinfettati , direi che è necessario che il CORE convalidi gli input.

Detto questo, dovresti creare un'API in cui ti aspetti di ricevere input sbagliati e restituire qualcosa di significativo per il chiamante, e non solo lanciando eccezioni strane e criptiche ovunque. "Garbage in, garbage out" è solo una cattiva progettazione dell'API.

Un approccio che ho utilizzato in passato con alcune applicazioni MVC5 era la creazione di una "BusinessException", che conteneva alcune informazioni chiave per il chiamante per capire che stavano usando l'API errata. Uno dei componenti di BusinessException era un "messaggio di errore intuitivo", che poteva essere mostrato direttamente a un utente in un'app Forms o in un'app Web (il core non sapeva mai dove era in esecuzione), insieme ad altri importanti campi come "FaultyProperty", "TechnicalException" e così via.

In questo modo puoi rendere la tua app MVC un thin layer eseguendo una validazione di base (molto semplice) prima di inviare il carico pesante al Core e mantenere un singolo modo idiomatico per gestire gli errori catturando la "BusinessException" quando necessario e reagendo di conseguenza .

In questo modo puoi mantenere il principio di responsabilità singola e DRY sul posto mantenendo le convalide e mantenendo il codice di facile lettura.

E restituendo i dettagli dell'errore al chiamante riempiendo campi / proprietà specifici in BusinessException, il livello della GUI può evidenziare qualsiasi cosa sia necessaria per fornire un'esperienza utente piacevole.

Per ricapitolare / confermare: si hanno due livelli di un'applicazione (nello stesso spazio del processo) in cui il livello esterno dell'applicazione sta eseguendo le convalide eseguite anche dal livello interno. Questo non deve essere confuso con la validazione lato client che riguarda l'esperienza utente. Ci sono fondamentalmente due percorsi principali che puoi intraprendere con questo: il modo semplice, o il modo complicato.

Il modo semplice è rimuovere la convalida ridondante. Puoi rimuoverlo dallo strato interno o dallo strato esterno. Avere solo lo strato esterno non ha molto senso per me. Avere due livelli significa che puoi usare lo strato interno in qualche altra soluzione. Si potrebbe anche riutilizzare il livello esterno in teoria, ma questo è probabilmente improbabile. Se riutilizzi il livello interno con qualche altro strato esterno, significa che devi duplicare la convalida lì o in qualche modo avere la possibilità di abilitare disabilitare la convalida sul core. L'approccio più semplice consiste nel mettere tutte le convalide 'core' nel livello interno e implementare solo la validazione nel livello esterno che è specifico per quel livello.

C'è una domanda di eccezioni. Il costo delle eccezioni è spesso sovra venduto. Ho fatto alcune analisi sul costo delle eccezioni in Java e 1. È completamente dipendente dalla profondità dello stack 2. Anche con stack veramente profondi (migliaia di chiamate) ho dovuto eseguire molte iterazioni solo per ottenere misurazioni significative. Mi aspetto che sia lo stesso per C #. Ti incoraggerei a fare qualche esperimento per vedere se questo è davvero un problema. L'utilizzo di questi per il controllo del flusso in modo Pythonistic è scoraggiato, ma proteggere il tuo sistema da dati errati è un caso in cui lanciare un'eccezione mi sembra perfettamente valida. se si vuole veramente evitare questo, è possibile utilizzare un qualche tipo di oggetto associato alla richiesta per tenere traccia degli stati e dei problemi. Questa potrebbe essere una buona idea se devi gestire avvertimenti o errori non fatali.

Il modo complicato consiste nell'usare una sorta di libro mastro nella logica di convalida per verificare se ciascuna convalida richiesta è stata eseguita sulla transazione specificata. Quindi il core non ha bisogno di rieseguire quella logica. È fantastico e quindi ci sono molte opportunità per creare nuovi problemi.

Un'eccezione da core non è probabilmente appropriata, dal momento che potresti avere più errori di convalida indipendenti in un set di dati di input e vuoi mostrare tutti gli errori nell'interfaccia utente. Quindi penso che l'approccio migliore sia quello di avere un metodo validate(InputDataSet) nel core che restituisce una collezione di errori di validazione per i dati di input.

Potresti fare in modo che il metodo di validazione restituisca un tipo diverso, a ValidatedDataset , se la convalida ha avuto successo. Quindi puoi fare in modo che i metodi commerciali accettino solo ValidatedDataset .

Se si tratta di un progetto interno con piccoli team, penso che si possa tranquillamente eliminare uno dei livelli di convalida. Se il progetto è di grandi dimensioni o complesso, oppure devi gestire più team o se terze parti accederanno alle tue API, probabilmente vorrai la convalida ridondante.

Se l'atto di convalidare qualcosa ha un sovraccarico dovuto alle ricerche nel database, prendere in considerazione l'implementazione di una cache comune. Inseriresti il tuo provider di cache nella root di composizione per assicurarti che tutti i livelli della tua applicazione usassero la stessa cache comune. Quando si verifica una convalida ridondante e deve interrogare il database per alcuni valori di ricerca, si verificherà un hit della cache e l'impatto sulle prestazioni sarà minimo.