没有Dispose（）SqlConnections有多糟糕？

就个人而言，如果我在使用语句中不放置实现IDisposable的ADO对象，就会陷入蜂巢。但是根据我目前的合同，我发现他们自己的企业框架“数据访问提供程序”代码不会1）实现IDisposable和2）在任何时候都对它使用的任何东西调用Dispose（）。用户一直在抱怨大量使用此框架进行数据访问的Winforms应用程序中的性能问题，尽管代码中还有很多其他问题可能会影响性能，但是这只是让我大叫，甚至更多。比其他人低垂的果实。

因此，除了说出“有某种原因而丢弃在这里，要使用它”之类的话，我还能告诉这些人说服他们这确实是真的吗？

我想说的是，您可以做的最好的事情就是将它们指向Microsoft的Dispose() 此处的模式和实践。让他们看到不使用摆在他们面前的该工具的全部后果。

如果未在SQL连接上调用Dispose方法，则在使用完该方法后，该连接不会返回到连接池中。

如果您遇到性能问题，我的猜测是在数据库上打开了最大连接数。DBA可以轻松确认这一点。

Microsoft的最佳实践要求您将连接代码放置在Using语句内，以确保连接已被处置，并且连接已返回到池中。

数据库连接池的大小受到限制，如果数据库连接池已满，则新连接将等待旧连接释放。如果您在完成处理后不立即处理它们，则最终将在finalizer运行时将它们释放，但这是未来的不确定时间...因此，充其量，您将打开新连接时会看到很长的延迟。

最糟糕的是，他们可能禁用了连接池。也许他们发现一段时间后，他们的应用程序返回“超时等待连接”错误并禁用连接池，从而“解决”了该问题。但是，这要糟得多，因为这意味着您每次都在创建一个全新的连接-令人惊讶的是，这会占用大量资源。如果您已经建立了数百个与数据库的连接，那么您会发现性能问题也就不足为奇了。

解决所有这些问题的正确方法是在连接完成后立即处理。最好的想法是将连接保持打开状态的时间长短完全正确，而不再需要。

在任何严肃的应用中，我都会说这是很糟糕的。不仅使这些对象浮出水面会破坏性能，而且完全是不专业的。好消息是Microsoft在对象层次结构中实现了Finalize。

~Object()
{
    this.Dispose(false);    
}

public void Dispose()
{
    this.Dispose(true);
    GC.SuppressFinalize(this);
}

protected virtual void Dispose(bool disposing)
{
    // ...
}

就拿System.Data.SqlClient.SqlConnection例如：

System.ComponentModel.Component <-实现Finalize处置模式。
    |
System.Data.Common.DbConnection
    |
System.Data.SqlClient.SqlConnection

这些对象最终将被处置，但不确定性会破坏性能。

好吧，对于您而言，您并没有终止连接。因此，它要么必须a）自动删除，要么b）循环浏览并更新，即使客户端没有使用它也是如此。

我假设b）由于您描述的性能下降。但是，这可能不是唯一的原因。

您必须关闭连接，最好是在客户端，但也必须在服务器端实现故障保护。否则，您将堆积很多垃圾，数据库服务器必须处理这些垃圾，直到它在天知道的时候发布为止。