C# 为什么在 asp.net MVC 控制器中需要显式的 Dispose() 方法？谁能解释一下它的复杂性？（特定于asp.net）
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10134406/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why is there need for an explicit Dispose() method in asp.net MVC Controllers? Can anyone explain its intricacies? (asp.net specific)
提问by Jan Carlo Viray
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?
我知道 C# 可以用它的垃圾收集器很好地管理资源。但是既然它有这个，它到底是做什么用的，为什么需要它？
Can anyone explain why .Dispose()is needed in asp.net mvc?
谁能解释为什么.Dispose()在 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.
另外，处理连接是什么意思？为什么需要它？任何人都知道为什么像 in 那样处理数据库连接很重要的复杂性db.Dispose()？这是 EF 相关的，还是 SQL Server 相关的？我试图确切地了解原因。
protected override void Dispose(bool disposing)
{
db.Dispose();
base.Dispose(disposing);
}
采纳答案by cHao
Disposeis 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 disposingflag signifies, BTW), for disposing other IDisposable objects it holds that are no longer useful.
Dispose用于释放“非托管”资源（例如，套接字、文件句柄、位图句柄等），并且如果它在终结器之外被调用（这就是disposing标志的含义，顺便说一句），用于处置它持有的其他 IDisposable 对象更有用。
"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 Disposemethod (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 hasa 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.
“非托管”资源不由 CLR 管理（因此得名），并且 GC 不会干扰它们或自行释放它们；如果没有Dispose方法（以及实际使用它的代码！），它将依靠对象的终结器来清理。最终终结器将运行（如果应用程序运行良好，并且对象有终结器），如果终结器完成它的工作，那么一切都还好……但是这样做需要花很多时间——如果你在此期间用完手柄，哦，好吧。对于其他线程/进程/任何需要它们的东西来说太糟糕了。
If you Dispose, though, the resources are released immediately, and things run better all around.
Dispose但是，如果您立即释放资源，那么一切都会变得更好。
(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.)
（顺便说一句，这不限于 EF、SQL Server 或任何其他技术。在整个 .net 框架中都可以找到 Disposable 模式，并且当您拥有不再使用的 IDisposable 时，利用它被认为是一种很好的做法用过的。）
As for why IDisposableis 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 Disposeit 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 Disposegets 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.
至于为什么IDisposable在树上实施到目前为止，而不是您只是根据具体情况实施它......我不是 100% 确定。但是想象一下你正在编写一个框架。考虑一下，如果所有东西都不是 IDisposable，你就必须检查——每次你想摆脱某些东西时！-- 该对象是否是一次性的，Dispose如果是。但是，如果您改为实现 IDisposable “以防万一”，那么事情就会简化——您只需始终处理即可。（如果一个对象没有任何要清理的东西，它就不会覆盖Dispose——在这种情况下，它的父对象的Dispose被调用并执行它必须做的任何清理工作，这也可能什么都没有...）对于控制器来说，清理东西是一个足够常见的情况，即使这不是真正的原因，它也很有意义无论如何要做。
