Probabilmente (come quasi sempre) arrivo buon ultimo su una questione evidentemente determinante per la scrittura di buon codice .NET: la gestione degli oggetti che implementano IDisposable e più in generale l'implementazione di tale interfaccia.
Avendo aperto un thread sul forum di UGISS, sono stato "gentilmente ripreso" da robertob che mi suggerisce di fare la Dispose() di alcuni oggetti (un OdbcCommand, un OdbcDataReader e un SqlCeCommand utilizzati nel mio sogente).
Orrore e sgomento: un Dispo-chè? Ma non c'è la Garbage Collection? E che cavolo, ma se devo fare tutto io a manina, a che serve 'sto framework del piffero?
Passati i primi 5 secondi di incavolatura, ho chiesto aiuto e sono stato indirizzato verso un paio di post di Marco Russo:
http://blogs.devleap.com/marco/archive/2005/01/10/2352.aspx
http://blogs.devleap.com/marco/archive/2004/12/01/2087.aspx
Infine, rapito dal sacro fuoco del sapere, googlando ho trovato un post davvero esaustivo sull'argomento:
Dispose, Finalization, and Resource Management di Joe Duffy
Per quelli che come me pensavano di poter lasciar fare tutto al Garbage Collector, cito due passaggi che sono stati "illuminanti":
Many people who hear about the Dispose pattern for the first time complain that the GC isn’t doing its job. They think it should collect resources, and that this is just like having to manage resources as you did in the unmanaged world. The truth is that the GC was never meant to manage resources. It was designed to manage memory and it is excellent in doing just that.
e
The only problem is that automatic management of memory and objects makes it difficult to ensure that resources held by objects are released deterministically (that is, early). The reliance on the GC can lead programmers to think that they don't need to worry about this anymore, which is not the case. In fact, any object that implements IDisposable should be mentally tagged with a red flag and should not be allowed to fall off the scene without Dispose having been called. The finalization/safe handle safety net is really not good enough to prevent lousy user experiences - such as a file remaining locked for an unexpectedly long time after "save" and "close" of a document window (but with the app still running). Careful use of AppDomains and their forced unloading (which triggers safe handles) is sometimes a way to deal with this rigorously.
Se poi non ne avete ancora abbastanza (io al momento sono "sazio" e fors'anche un po' abbottato), nel post di Raj Chanian trovate pane per i vostri denti (un bell'elenco di link, tutti da leggere).
Infine una domanda: è mai possibile che un argomento così importante NON sia incluso nelle cose da studiare per passare l'esame 70-536 (Microsoft .NET Framework 2.0 - Application Development Foundation) ?
Non ho parole...