Menu
I know C# can manage resource pretty well with its garbage collector. But since it has that, what exactly is this for and why is it needed?
Can anyone explain why .Dispose() is needed in asp.net mvc?
Also, what does it mean to Dispose a connection? Why is it needed? Anyone know the intricacies of why it's important to dispose a database connection like in db.Dispose()? Is this EF-related, or SQL Server-related? I'm trying to understand exactly why.
protected override void Dispose(bool disposing) { db.Dispose(); base.Dispose(disposing); } 
589
The Dispose(Boolean) method overload is the preferred method to override. If you derive a class from Controller and the derived class uses unmanaged memory, managed operating-system resources (such as files), or COM objects, you should implement Dispose to clean up these resources.
The dispose pattern is used for objects that implement the IDisposable interface, and is common when interacting with file and pipe handles, registry handles, wait handles, or pointers to blocks of unmanaged memory. This is because the garbage collector is unable to reclaim unmanaged objects.
In the context of C#, dispose is an object method invoked to execute code required for memory cleanup and release and reset unmanaged resources, such as file handles and database connections.
Dispose is for releasing "unmanaged" resources (for example, sockets, file handles, Bitmap handles, etc), and if it's being called outside a finalizer (that's what the disposing flag signifies, BTW), for disposing other IDisposable objects it holds that are no longer useful.
Dispose is for releasing "unmanaged" resources (for example, sockets, file handles, Bitmap handles, etc), and if it's being called outside a finalizer (that's what the disposing flag signifies, BTW), for disposing other IDisposable objects it holds that are no longer useful.
"Unmanaged" resources aren't managed by the CLR (hence the name), and GC doesn't mess with them or free them all by itself; absent a Dispose method (and code actually using it!), it'll rely on the object's finalizer to clean up. Eventually the finalizer will run (if the app's healthy, and the object has a finalizer), and if the finalizer does its job then all's semi OK....but it'll take its sweet time in doing so -- and if you run out of handles in the meantime, oh well. Too bad for that other thread/process/whatever that needed them.
If you Dispose, though, the resources are released immediately, and things run better all around.
(By the way, this is not restricted to EF, SQL Server, or any other technology. The Disposable pattern is found throughout the .net framework, and it's considered good practice to take advantage of it whenever you have an IDisposable that's no longer being used.)
As for why IDisposable is implemented so far up the tree, rather than you just implementing it on a case by case basis...i'm not 100% sure. But imagine you were writing a framework. Consider that if everything weren't an IDisposable, you'd have to check -- every time you wanted to get rid of something! -- whether the object is disposable, and Dispose it if so. If you instead implement IDisposable "just in case", though, things are simplified -- you just always dispose. (If an object doesn't have anything to clean up, it just doesn't override Dispose -- in which case its parent's Dispose gets called and does whatever cleanup it has to, which may be nothing as well...) And it's a common enough case for controllers to have stuff to clean up, that even if that's not the real reason, it makes a lot of sense to do anyway.
128
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
