Cosa hanno in comune IDataReader e DataRow e DataRowView? Sicuramente il fatto che in modo o nell'altro rimappano un record... sia esso recuperato da db sia esso caricato da altra fonte dati. Mi sono smepre chiesto come mai solo il Datareader implementa IDataRecord... cosa che per altro non ho mai capito.
Questa mancanza di interfaccie comuni tra gli oggetti elencati a volta ci porta a dover implementare mappature doppie tra sorgente dati e custom object, che non sempre potrebbero arrivare da un DataReader.
Qualche settimana fa eccomi allora tornato alla carica sul problema cerando di trovare una soluzione... e quella sera decisi di provare la via di Reflection, i tre oggetti avevano si un metodo in comune anche se non formalizzato da interfaccie...le classi sono infatto indicizzabili per stringhe (nome campo corrisponde valore). Alla fine sono arrivato alla creazione di un wrapper che faceva uso di reflection e delegate... grande mi sono detto, ma il codice - ovviamente - perdeva in leggibilità :o Ho guardato e riguardato il codice, la soluzione era il patern factory e implementare wrapper non generici ma tipizzati e verticali per i singoli oggetti...forse qualche riga di codice in più ma decisamente più solida e leggibile, al punto da sembrare banale.
Non posto qui il codice delle mie prove perchè rischio di rubare - maleducamante - tutto il muro... ho messo il listato in un articolo che potete leggere qui, Reflection vs Factory pattern . (Per meglio leggerlo conviene copiare il codice in Visual Studio o in un editor .NET che ne fa le veci).