Me lo chiedo perché la vedo raramente usata nei forum e nel codice che mi capita di guardare e mi domando il perché, visto che è così comoda da usare. Beh il mio consiglio è: qualsiasi oggetto create, se implementa IDisposable, usate sempre la using.
Per i seguenti motivi:
- Occorre sempre chiudere risorse unmanaged in modo esplicito e il prima possibile. Se si demanda il lavoro al Garbage Collector il Dispose verrà effettuato sfruttando la Finalize e l'oggetto resterà nell'heap per un giro di GC in più e rischiamo inoltre che l'oggetto diventi più forte come generation e non venga più rimosso;
- Anche se l'oggetto non fa uso risorse unmanaged, la Dispose va chiamata lo stesso. Primo perché non possiamo mai sapere se in una futura versione l'oggetto utilizzerà tali risorse e secondo perché chiamando Dispose, se la classe è scritta bene, viene chiamato GC.SuppressFinalize(this) così da togliere l'oggetto dalla finalization list, il GC lo rimuoverà dall'heap e il problema indicato nel primo punto non si verificherà.
Se scriviamo delle nostre classi che fanno uso di risorse unmanaged o di classi che a loro volta ne fanno uso, vi consiglio di ereditare da System.ComponentModel.Component. Implementa già il pattern Dispose, con l'interfaccia IDisposable, il metodo Finalize e mettendo a disposizione un metodo virtuale Dispose(bool disposing). Una tipica classe è così:
public class MiaClasse : System.ComponentModel.Component { private bool disposed; public void MioMetodo() { if (disposed) throw new ObjectDisposedException(base.GetType().Name); } protected override void Dispose(bool disposing) { if (disposing) { risorsaunmanaged.Dispose(); } risorsaunmanaged = null; this.disposed = true; base.Dispose(disposing); } }
L'uso della variabile disposed è "facoltaltiva", ma utile se vogliamo lanciare un eccezione nel caso qualcuno chiami un nostro metodo quando ne ha già chiamato il Dispose.
Quindi insomma, usiamo la using che non vi costa e scriviamo le classi nel modo giusto ;-)
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
- LINQ, lazy loading e architettura, l'11 marzo 2011 alle 18:42
- MetadataDiffViewer: aggiornato al .NET Framework 4.0, Silverlight 4.0 e Sharepoint 2010, il 7 gennaio 2010 alle 13:58
- .NET Framework 4.0 beta 1: Windows Communication Foundation, il 18 maggio 2009 alle 16:00
- Parallelizzare in Silverlight 2.0, il 21 aprile 2009 alle 00:25
- Silverlight: performance dell'isolated storage, il 16 aprile 2009 alle 17:38
- MetadataDiffViewer: differenze tra i framework, il 15 aprile 2009 alle 18:56