Best practice per il controllo degli argomenti

Se null non è valido sul servizio web, quindi controllalo nel servizio web.

Se è sempre valido, aggiorna il codice. Non preoccuparti di implementare cose che al momento non esistono e non sai se esisteranno mai.

Sai già che null non è valido, quindi prendilo immediatamente.

Se c'è un solo parametro e null diventa valido, potresti voler creare un metodo senza parametro come opzione in futuro in modo che l'utente non debba passare nulla per ottenere la funzionalità di cui hanno bisogno.

Personalmente, dipende da cosa sta succedendo nei metodi. Se il metodo intermedio lo sta solo scaricando, non lo controllerei. Il metodo che deve validare il parametro esegue il controllo. Anche se il parametro è controllato a monte, il metodo che necessita di un parametro valido deve essere controllato.

Se passedValue viene utilizzato in MyWebServiceMethod o MyServiceMethod in alcun modo oltre a chiamare MyServiceMethod e MyRepositoryMethod , dovrai controllarlo in quei luoghi in modo tale che qualsiasi codice in ciascuno di questi i livelli che consumano passedValue hanno un valore valido con cui lavorare.

Se, d'altra parte, per ogni livello passedValue è solo usato per chiamare nel livello successivo, controllarlo sul livello più interno e consentire alle eccezioni di far comparire all'utente Là. In questo modo hai solo un posto per mantenere il codice, se le aspettative cambiano.

A parte questo, non preoccuparti troppo dei futuri consumatori di qualsiasi livello. Se MyServiceMethod cambia in seguito per utilizzare passedValue in altri lavori, lo sviluppatore che aggiunge tale funzionalità dovrebbe comprendere le implicazioni di tale modifica e proteggersi di conseguenza.

Secondo me, dipende molto da come verrà utilizzato il codice. Se il codice (classi, ecc.) Che stai creando verrà riutilizzato in diversi modi - o da altre persone - allora potresti voler avere più livelli di controllo (se necessario - potrebbe essere giusto lasciare solo un si verifica un'eccezione di riferimento null). Ma se è più probabile che venga tenuto in una piccola squadra (o te stesso), puoi gestirlo ovunque tu voglia, e prima potrebbe essere meglio di dopo.

Nella mia mente, è lo stesso tipo di idea di come si dovrebbe fare null di controlli. Alcune persone dicono di farle ovunque qualcosa potrebbe essere null perché questa è "programmazione difensiva". Ma se controlli il codice e sai che null non accadrà, allora i controlli sono solo uno spreco.

Should I check passedValue and throw an exception in:

• The Web Service
• The Service
• The Repository

Che cosa hai intenzione di fare se la stringa è nullo? Lanciare un'eccezione di argomento illegale per prevenire un'eccezione del puntatore nullo?

Non verrei controllato a meno che il mancato rispetto di questo potrebbe portare a un buco di sicurezza. Un'eccezione di puntatore nullo seguita da un errore 404 o altro è una risposta ragionevole a un utente che digita un URL non valido per una chiamata al servizio web. È anche una risposta ragionevole quando una pagina web costruisce un URL errato. Un'eccezione di puntatore nullo è una risposta ragionevole a uno sviluppatore che passa un argomento nullo a una funzione che non è documentata per accettare un null.

Ci sono molti modi in cui un argomento può essere inutilizzabile. Un riferimento a un oggetto può essere nullo. Un valore in virgola mobile può essere infinito o NaN. Un flusso di output potrebbe non essere aperto. Sono state inventate eccezioni per eliminare la necessità di controllare tutte queste condizioni ad ogni livello del codice.

2 soluzioni:  - null è o può diventare un valore valido per il tuo servizio. In tal caso devi passarlo lungo il tuo stack.  - Se il valore nullo è vietato, la convalida di base è migliore al livello superiore (servizio web) per evitare chiamate non necessarie.

Dato il caso, che hai un metodo che chiama solo un altro metodo e passa gli argomenti, a quel punto non è necessario controllare se una variabile è nullo. Quando viene chiamato il repository, devi decidere se null è un valore valido o meno. In caso contrario, è necessario testare la variabile su null e generare un'eccezione.

Finché un "livello" espone un'interfaccia pubblica con un contratto, è necessario verificare il valore nullo. Quindi nel tuo caso dovresti avere 3 assegni nulli. Ciò ti consentirà di essere infallibile se MyServiceMethod o MyRepositoryMethod vengono richiamati da qualche altra parte.