Come risolviamo tutto questo "La conversione da tipo DBNull a tipo String non è valida" nastiness?

Question

Nelle nostre applicazioni, non posso pensare a molti casi in cui ci preoccupiamo dei campi stringa null. Vogliamo solo che mostrino come stringhe vuote nella maggior parte delle situazioni.

Così, quando con il costruito in ADO.NET dataset/DataTable, l'errore:

Conversion from type DBNull to type String is not valid

è fin troppo comune in seguito in app quando ci si riferisce a tutti i dati di stringa vecchi.

Si tratta di un problema particolare, perché può prendere noi fuori così facilmente (e spesso non è visto nei test)

So che ci sono diverse soluzioni:

1. Verificare la presenza di .IsXXXNull in tutti i casi

Ma:

• che è un compito noioso alcune linee extra di Codice in tutto l'app

• se dimentichiamo il controllo, anche 1 volta in 100, abbiamo un potenziale errore in agguato

2. Nella finestra di progettazione set di dati, modificare la NullValue proprietà del campo dal default "Eccezione Throw" a "vuoto"

Ma:

• abbiamo avuto modo di identificare e cambiare ogni tavolo e ogni campo di stringa aggiungiamo al progettista dataset (ricordate il default è "Throw eccezione")

• se si dimentica il cambiamento anche 1 volta in 100 , abbiamo un potenziale errore di agguato

3. Evitare di conservare Null nei dati di base

Ma:

• Abbiamo avuto modo di identificare e cambiare ogni tavolo e ogni campo di stringa aggiungiamo al database

• non sempre avere quel tipo di controllo sui dati di base

4.Non utilizzare il designer set di dati, estrarre i dati nei nostri oggetti propri di classe, che fare con tutto il disordine DBNull nel nostro codice

Ma:

• sì, noi lo facciamo per il nostro "grande" tabelle. ma il progettista insieme di dati è un bel modo rapido a tirare in un elenco di selezione o tabella di ricerca, dove abbiamo solo bisogno il comportamento predefinito di dati

5. Utilizzare un generatore di codice o di un quadro, come CSLA invece di DataSets

Ma:

• grande passo per risolvere un piccolo problema ... la seconda risposta per la classifica top domanda su SO tagged CSLA cita: "E 'contro sono che ha un po' di al curva di guadagno. "

Answer 1

Questo è il motivo per cui DataSet e DataTable sono:

1. Buon per mettere rapidamente insieme un'applicazione che utilizza semplice accesso ai dati (come si parla).

2. Non valido per un'applicazione enterprise ben progettata: ci sono troppe semplificazioni e generalizzazioni.

Ho trovato che utilizzando un modello a oggetti consapevoli di associazione dati corretta quasi sempre la meglio utilizzando DataSet e DataTable, e possono avere tutto (e più!) Il funcionality, facilità d'uso e velocità di utilizzando DataSet e DataTables.

E non ci si imbatte in problemi come questi, perché il modello di business non è strettamente collegato alla struttura del database.

Devo ancora incontrare qualcuno che abbia utilizzato un framework come CSLA.NET e desidera tornare a DataSet e DataTables.

Answer 2

5. (o forse 4b)

utilizzano un quadro che fornisce la funzionalità NULL per voi nella vostra classe di accesso ai dati. Il già citato framework CSLA.NET (di Riko) utilizza una classe SafeDataReader, che funziona esattamente come un DataReader, ma può convertire tutti i NULL in valori vuoti per i livelli di accesso ai dati e di logica aziendale.