Ok, spero innanzitutto che Oscar Wilde non si stia troppo lamentando per la citazione a sproposito presente nel titolo :-) Ciò premesso, questo tip appena pubblicato su UGIdotNET mi ha riportato alla mente un episodio che descrissi in questo post: più che sull’argomento in sè ho riflettuto sul fatto che nell’anno 2000, quando mi trovai a dover risolvere il problema citato nel post, spesi svariate giornate per giungere alla soluzione ivi descritta perchè per scoprire l’esistenza di quella modalità di scrittura “non logged” di SQL Server dovetti spulciare la documentazione di SQL Server ed altrettanta ne spulciai per capire come, utilizzando le estensioni custom del suo driver ODBC, trarre vantaggio da quella tecnica.
Per certi versi si trattò di un interessante esercizio speculativo che mi lasciò in dote qualche conoscenza in più in merito ad alcuni internals di SQL Server, ma con il senno di poi penso che i servizi offerti dalla classe SqlBulkCopy sono un ottimo esempio di cosa dovrebbe fare un framework, ossia offrire delle primitive ad un (ragionevole) livello di astrazione che permetta allo sviluppatore di dedicare il proprio tempo alla soluzione della parte “pregiata” (si ok, si scrive “pregiata” ma si legge “domain”…) di un problema potendo far affidamento su un substrato tecnologico che sia in grado di sfruttare la tecnologia/piattaforma sottostante.
In questo senso, nonostante l’ipertrofia che ormai lo caratterizza, penso a quanto valore ci sia nel .NET Framework che ormai diamo per scontato e quanto avrei preferito, mentre nel 2000 dovevo risolvere da solo il problema in oggetto, aver a disposizione SqlBulkCopy potendo dedicare meno tempo al lavoro e magari usare il tempo risparmiato per un Mojito in buona compagnia… :-)