Qualche articolo prima avevo proposta una classe di supporto per la lettura dei dati con il datareader, DataRecordSupport.
Il supporto offerto da questa classe è quello di evitare la routine di codice per identificare i DbNull ed evitare quindi di incappare nelle sgradevoli InvalidCastException.
Nel post SafeDataReader e "Lettura dei dati e DbNull" (ero in ferie e quasi mi stava sfuggendo) Adrian faceva notare come un idea molto simile alla mia era stata proposta da Rocky Lhotka nella sua CSLA.Data.SafeDataReader.
Beh sono contento... significa che non ho proprio avuto un idea così malvagia visto che l'abbiamo pensata in due :-D
...e pensare - come ho commentato nel sul blog di Adrian - quando ho proposto la cosa nel NG di whidbey, microsoft.private.whidbey.adodotnet (qui raggiungibile via web http://communities.microsoft.com/newsgroups/default.asp?icp=whidbey&slcid=us), non ero riuscito a spiegare lo scopo della classe e il thread ha così deviato su un _accessa_ discussione sull'uso dei NULL nel Database...
Le due classi coso proprio uguali? beh non esattamente... se devo essere sincero preferisco la mia implementazione.
La prima differenza è che io ho scelto di fare un wrapper su IDataRecord mentre Rocky su IDataReader... ma questo è il meno. Quando l'ho pensata sono stato combattuto su quale interfaccia wrappare, ma poi ho optato per IDataRecord in quanto io voglio triggerare i metodi di lettura dei dati e non quelli per scorrere i record.
La grossa differenza è che io rimappo i metodi pari pari per quel che riguarda l'interfaccia IDataRecord e aggiungo gli overload ai vari metodi in modo che sia il chiamante a decidere quale è il valore da associare nel caso un dato sia DbNull. In quasto modo non perdo nulla delle funzionalità del DataReader standard e ne aggiungo altre. Preferisco che sia il chiamante a decidedere che valore associare a un campo se è DbNull in quanto il valore con cui rimappere nell'applicazione un DbNUll dipende dal contesto. Infatti in alcuni casi un DbNUll su un Int32 è corretto rimapparlo con uno "0"... ma magari in altri casi è corretto rimapparlo con un "-1" poichè "0" ha un significato ben preciso. Poichè la GetInt32 - come nel caso della SafeDataReader - mi torna sempre "0" sono costretto a fare il classico test IsDbNull quando DbNull ha un'altro significato. Il valore aggiunto della DataRecordSupport è che non ha logica Business interna: è una classe _stupida_. Non è lei a decidere quali sono _i valori di default_ ma è sempre il chiamante a farlo ...e credo che così debba essere! Decidere quale è il valore da associare/rimappare nel caso di DBNull non è compito delle classi di utilità ma è compito delle classi di Business! La DataRecordSupport vuole essere una classe di utilità!
posted @ sabato 11 settembre 2004 18:11