我应该在我的数据访问层中坚持sqlconnection吗？

似乎有很多开销涉及快速打开和关闭sqlconnections。我应该坚持一个连接（每个客户端，每个数据库一个连接），还是在我需要的时候继续声明一个新的sqlconnection对象，并确保自己清理完毕？我应该在我的数据访问层中坚持sqlconnection吗？

你做了什么？什么效果好，什么效果不好？

来源

2008-10-29 tom.dietrich

何时连接在游泳池超时？ – 2008-10-29 15:46:08

您可以通过connectionstring名称/值来控制它：http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx。向下滚动到包含“连接寿命”的第二个表格。 – 2008-10-29 16:08:50

在大多数情况下，.NET连接池为您处理此问题。即使你通过代码打开和关闭连接，这不是幕后发生的事情。当您实例化并打开连接时，.NET将使用相同的连接字符串查找连接池中的现有连接，并为您提供相同的连接。当您关闭连接时，它将返回到连接池以供将来使用。

如果您使用的SQL Server：http://msdn.microsoft.com/en-us/library/8xx3tyca.aspx

OLE DB，ODBC，甲骨文：http://msdn.microsoft.com/en-us/library/ms254502.aspx

迪诺·埃斯波西托文章：http://www.wintellect.com/Articles/ADO%20NET%20Connection.pdf

您可以覆盖与ConnectionString的名称/值默认池的行为： http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx。查看包含'连接寿命'的第二个设置表。

来源

2008-10-29 15:40:10

如果您使用相同的连接字符串，您将连接到连接。只要你需要它，你只应该打开一个连接。

来源

2008-10-29 15:29:24 jonnii

由于默认设置，池存储在连接池中，所以没有太多开销。因此，当您打开连接时，通常您只需从池中获得现成的连接。创建SqlConnections并没有给我任何麻烦。

来源

2008-10-29 15:30:37

我的确有同样的想法，所以我在紧密循环中使用了相同的连接，以防止在需要时实例化另一个连接。但有时很难跟踪它并进行调试，如果您将DataReader从连接中取出，然后尝试在同一个读取器仍处于活动状态时再执行一次，则会发生异常。所以，我只会推荐它，如果它确实频繁像一个紧密的循环，否则它是不值得的麻烦。

来源

2008-10-29 15:39:32 faulty

这通常不是一件好事（你可能会导致泄漏并最终用完连接），而是依赖于连接池来提高性能并根据需要打开连接，并尽可能快地关闭连接。

比尔·沃恩有很多关于连接池和包括this one

来源

2008-10-29 17:22:35

数据访问有用的文章多年来，我们有客户存到数据库中的一个永久连接。问题在于检测到间歇性连接失败并正常重新连接。通常你不会知道连接失败，直到你尝试使用它（例如发出一个select会抛出一个'General SQL Error'）

我们现在使用一个全局可用的静态类，它的工作是给你一个与数据库的新连接，当你完成它时，你使用相同的类来摆脱连接。

DbConnection conn = Database.GetConnection(); 
try 
{ 
    //do stuff with the connetion 
    ... 
} 
finally 
{ 
    Database.DisposeConnection(conn); 
}

我们做到这一点，因为有当我们连接到数据库所需的初始化（我们存储的信息是SQL Server的CONTEXT_INFO，当我们断开必须清空该信息）

来源

2008-10-29 18:05:45

我应该在我的数据访问层中坚持sqlconnection吗？

回答

相关问题