Convalida le migliori pratiche, proprietà vs dto, tipo semplice contro oggetto

Question

Convalida le migliori pratiche, proprietà vs dto, tipo semplice contro oggetto

#1 da (3 voti)
#2 da (1 voti)
#3 da (0 voti)

4

Considera un'applicazione in cui aggiungi un indirizzo email al suo profilo e lo invia.

Abbiamo qualche controversia nel nostro team su come convalidare questo indirizzo email. Alcuni sviluppatori (incluso me) credono che dovremmo convalidare questa semplice stringa tramite un metodo di estensione:

bool isValid = newEmail.IsEmail();

Sostengono che qualsiasi meccanismo di validazione diverso da una singola chiamata al metodo sarebbe overhead e un anti-pattern (contro il principale di KISS).

Mentre altri sostengono che questa email dovrebbe prima essere aggiunta a una nuova istanza di UserEmail DTO, allora tale DTO dovrebbe essere passato a un validatore pertinente:

UserEmail userEmail = new UserEmail() { Email = newEmail };
bool isValid = new UserEmailValidator().Validate(userEmail);

Il secondo gruppo sostiene che la convalida di una singola proprietà non ha senso, perché una proprietà non può esistere da sola. Quindi dovremmo sempre convalidare un oggetto, non una proprietà (intendo, proprietà del tipo di valore, come stringhe e interi, ecc.)

Quali vantaggi e svantaggi potrebbero avere ciascun approccio?

programming-practices validation

posta Saeed Neamati 15.08.2012 - 12:53

fonte

3 risposte

Leggi altre domande sui tag programming-practices validation

Esiste un modo migliore per modellare una relazione molti-a-molti sulla stessa tabella con Entity Framework? Come posso fare in modo che il codice venga esaminato da qualcuno che non conosce la lingua più facilmente?

score 3 · Answer 1

Dipende dalle tue regole di validazione. Il controllo di un indirizzo email correttamente formattato può essere una semplice chiamata di metodo. Controllare che un indirizzo email esista effettivamente o che non sia già in uso da qualche altra parte richiede un contesto più ampio che di solito non è appropriato come parte di un campo semplice.

Dove non sono d'accordo, in ogni caso lo sta avvolgendo in un DTO invece di passare semplicemente la stringa direttamente in Validate() . Se elimini la prima linea, la seconda soluzione improvvisamente non sembra così orribilmente complessa.

score 1 · Answer 2

Supponendo di avere almeno 2 livelli:

They argue that any validation mechanism other than a single method call would be overhead, and an anti-pattern (against KISS principal).

Non sempre vero. Potrebbe essere necessario eseguire la convalida sul client non appena vengono inseriti dati errati senza logica e i dati passano al livello successivo. In questo caso, è necessario convalidare la sintassi e-mail sul client e farlo di nuovo sul server (potrebbe essere con ulteriori regole aziendali come un controllo di unicità).

While others argue that this email should first be added to a new instance of UserEmail DTO, then that DTO should be passed to a the relevant validator:

Supponiamo che il modulo abbia 10 campi che potrebbero essere in errore, l'utente immette l'e-mail come "abc" e schede nel campo successivo, ora vuoi avvisare l'utente? Se si desidera farlo, è necessario passare l'intero oggetto client e convalidarlo. il validatore restituirà 10 errori indietro che potrebbero confondere l'utente dal momento che tutto ciò che ha fatto è di andare in tab, non è stato premuto alcun pulsante di azione. Aggiungete a ciò il sovraccarico dello spostamento dei dati tra i livelli e vedrete che questo non è abbastanza valido.

The second group argues that validating a single property makes no sense, because a property can't exist on its own.

Questo a volte è vero, ma non sempre vero. Nel caso del valore email di "abc" o nel caso di saltare un campo obbligatorio, puoi dire che esiste un errore indipendentemente dagli altri dati inseriti nel modulo.

In sintesi, devi decidere lo stile dell'esperienza utente e rispettarlo in tutte le pagine / moduli della tua applicazione. Prendi in considerazione che i costi di convalida viaggiano tra livelli e possono causare ritardi. Inoltre, troppa convalida + ritardo in una forma grande è una cosa negativa. In tutti i casi non si trasmette mai il solo risultato di convalida di un livello. È necessario eseguire tutti i controlli necessari prima di inviare i dati al database. Per questo motivo, progetta la tua logica di convalida per essere riutilizzabile su più livelli il più possibile.

score 0 · Answer 3

The second group argues that validating a single property makes no sense, because a property can't exist on its own.

Solo perché una proprietà non può esistere senza una classe non significa che un indirizzo email debba essere all'interno di una classe per essere convalidato. Un indirizzo e-mail non ha bisogno di altre proprietà oltre a se stesso per essere convalidato - IsEmail () è bello e semplice per me. Ovviamente se vuoi riunire tutte le tue convalide in un'unica posizione, allora crea una classe di validazione.