什么时候应该打开和closures连接到SQL Server
我有一个简单的静态类，其中有几个方法。 每个方法打开一个SqlConnection，查询数据库并closures连接。 这样，我确信我总是closures与数据库的连接，但另一方面，我不喜欢总是打开和closures连接。 下面是我的方法的例子。
public static void AddSomething(string something) { using (SqlConnection connection = new SqlConnection("...")) { connection.Open(); // ... connection.Close(); } } 考虑到方法是在一个静态类，我应该有一个静态成员包含单个SqlConnection？ 我应该如何以及何时放弃它？ 什么是最佳实践？
不，不要保持静态的SqlConnection除非你必须。 线程将是一个问题，但更重要的是 – 通常你根本不需要。 使用你的代码，内部连接池意味着大多数情况下你会在连续的调用中获得相同的底层连接（只要你使用相同的连接string）。 让池塘干活吧。 单独留下代码。
这也避免了当你开始有两个线程时会发生什么问题……现在每个人都可以在自己的连接上工作; 与静态（假设你不使用[ThreadStatic] ），你必须同步，引入延迟。 更不用说重新进入（即一个线程试图同时使用同一个连接两次）。 对; 单独留下代码。 现在没事了，几乎你所做的任何改变都会使它不好。
由于SqlConnection在调用Open（）和Close（）时具有连接池，因此实际上并不打开和closures与服务器的物理连接。 您只需添加/删除可用连接池中的连接。 因此，尽可能晚地打开连接并在执行命令后尽可能早地closures连接是一个不错的最佳实践。
在你的代码示例中，不需要在连接对象上调用close（）方法，因为代码将驻留在using块中，因此将自动处理。
大多数程序员相信开放迟到和早期closures。 如果每次打开和closures连接的延迟导致整个应用程序变慢，这只是一个问题。
对于静态类，最好每次打开和closures连接。
你正在做最好的做法。 只有在你打算查询之前打开它，尽快closures它。 这种事情一开始可能看起来很浪费，但从长远来看，这实际上会使您的应用程序更具可扩展性。
永远不要依赖连接来closures自己。 如果没有明确closures，则会导致性能问题。 这发生在我们的项目上。 是的，我知道连接是由连接池pipe理的，但是他们仍然需要closures并返回到池中。
