汇集人脉对我来说有多重要？

Question

有人建议我重新安排我的代码以“池化”我的 ADO 连接。在每个网页上，我都会打开一个连接并继续使用相同的打开连接。但其他人告诉我，这在 10 年前很重要，但现在不那么重要了。如果我在网络发布上进行 5 个 db 调用，那么使用我打开/关闭的 5 个单独的连接是否有问题？

Answer 1

与 SQL Server 的连接自动汇集在 ASP.NET 应用程序中：每个不同的连接字符串对应一个池。如果您遵循最佳实践并将数据库代码隐藏在连接字符串在整个应用程序中保持不变的 DAL 中，那么您将始终使用单个连接对象池。

那么这对于您的数据库方法意味着什么？嗯，一方面，这意味着“关闭连接”实际上转化为“将连接返回到池”，而不是真正关闭应用程序与 SQL Server 的链接。因此，关闭和重新开放并不是什么大事。然而，话虽如此，这里还是有一些最佳实践可供遵循。

首先，即使您的应用程序急剧扩展，您也不希望耗尽池中的连接。也就是说，永远不要轮流考虑“此页面上的用户” - 考虑“使用此页面的上千人”。

其次，尽管关闭和重新打开连接并不那么费力，但您通常会希望尽可能晚打开连接，使用它直到完成，然后将其关闭<尽可能早。唯一的例外是，如果您有一个耗时的过程，该过程必须在检索某些数据之后以及保存或检索其他数据之前进行。

第三，我强烈建议不要在页面生命周期的早期打开连接并在生命周期的后期以不同的方法关闭它。为什么？因为您能做的最糟糕的事情就是让连接保持打开状态，因为您忘记添加关闭它的逻辑。是的，当 GC 启动时，它们最终会被关闭，但是，再次，如果您正在考虑“成千上万的人使用此页面*，那么真正遇到麻烦的机会就变得显而易见了。

现在，如果你说你确定你关闭了连接，因为你总是在一些关键的、合乎逻辑的地方这样做（例如Page_Unload方法），那么只要你可以自信地说，这就很好。你永远不会抛出跳出页面生命周期的错误。所以，不要在页面生命周期的一种方法中打开并在另一种方法中关闭

。建议实现管理数据库连接并提供处理数据的工具的 DAL，构建一个业务逻辑层 (BLL)，使用这些工具向 UI 提供类型安全对象（例如“模型”对象）。如果您使用 IDisposable 接口实现 BLL 对象，那么您始终可以使用作用域确保连接安全。它还可以让您在非常时间内保持数据库连接打开：只需打开BLL 对象，将数据拉入本地对象或列表，然后关闭 BLL 对象（超出范围）。然后，您可以在连接关闭后使用 BLL 返回的数据。

那么...这看起来像什么。那么，在您的页面（UI）上，您将使用如下所示的业务逻辑类：

using (BusinessLogicSubClass bLogic = new BusinessLogicSubClass())
{
   // Retrieve and display data or pull from your UI and update
   // using methods built into the bLogic object
    .
    .
    .
}  // <-- Going out of scope will automatically call the dispose method and close the database connection.

您的 BusinessLogicSubClass 将从实现 IDisposable 的 BusinessLogic 对象派生。它将实例化您的 DAL 类并打开一个连接，如下所示：

public class BusinessLogic : IDisposable
{
    protected DBManagementClass qry;
    public BusinessLogic()
    {
        qry = new DBManagementClass();
    }

    public void Dispose()
    {
        qry.Dispose();  <-- qry does the connection management as described below.
    }

    ... other methods that work with the qry class to 
    ... retrieve, manipulate, update, etc. the data 
    ... Example: returning a List<ModelClass> to the UI ...

 }

当 BusinessLogic 类超出范围时，将自动调用 Dispose 方法，因为它实现了 IDisposable 接口。

您的 DAL 类将具有匹配的方法：

public class DBManagementClass : IDisposable
{
    public static string ConnectionString { get; set; }  // ConnectionString is initialized when the App starts up.

    public DBManagementClass()
    {
        conn = new SqlConnection(ConnectionString);  
        conn.Open();
    }

    public void Dispose()
    {
        conn.Close();
    }

    ... other methods
}

根据我到目前为止所描述的内容，DAL 不具有 IDisposable 属性。但是，当我测试新的 BLL 方法时，我在测试代码中广泛使用 DAL 类，因此我将 DAL 构造为 IDisposable，以便我可以在测试期间使用“using”构造。

遵循这种方法，本质上，您将永远不必再考虑连接池。

Answer 2

如果您将 ADO.NET 与 SQL Server 一起使用，那么您的连接可能已经被池化。连接池是当今数据库中非常常见的做法，大多数时候您在不知情的情况下使用连接池。我的猜测是，您被告知手动池化连接并不那么重要，因为现在它通常是自动的。

这是一个很好的做法，原因有几个。其一，创建连接需要一定的时间，而不断关闭和打开连接可能会浪费宝贵的时间。其次，连接通常是有限的资源，不应该被浪费。通常，堆栈级别的限制也会阻止打开连接的频率。在高吞吐量环境中，实际打开和关闭连接可能会耗尽有限的资源，并在它们慢慢恢复可用时产生瓶颈。

Answer 3

从框架 2.0 开始，ASP.NET 默认池化与 SQL Server 的连接。

然而，与你交谈过的人所谈论的并不完全是池化。相反，它是关于减少数据库会话的数量。

由于连接是池化的，关闭一个连接对象并打开另一个连接对象的代价非常小。通常发生的情况是数据库连接本身返回到连接池，当您创建下一个连接对象时，它只是使用您刚刚返回的相同连接重新建立数据库连接。

不过，由于每次重新建立连接时都会向数据库发出请求，因此如果可能的话，您应该尝试减少使用的连接对象的数量。

页面循环使得保持连接对象对所有数据库操作保持打开状态有点困难，因此我通常做的是使用一个连接对象来定期获取 Page_Load 中完成的数据，然后如果需要的话使用另一个连接，例如在按钮事件来更新数据库中的数据。

Answer 4

我想说，汇集任何东西的连接是个好主意。几乎所有事物都有有限的连接限制。此外，打开连接会产生相关开销，因此使用相同的连接会更加高效并节省响应时间。

如果扩展到 15 个数据库调用会怎样？这些联系开始堆积。

池他们。没有理由不这样做。

当然，现在服务器可以处理任何事情，但是您可以节省的任何响应时间都可以改善用户体验。

Answer 5

无论如何，ADO.NET 通常都会汇集您的连接。有时这被认为是一件好事；它努力做正确的事，可能不会造成任何悲伤。

您不需要做任何特殊的事情来实现这一点，除了每次使用相同的参数创建连接（这并不困难，只需使用相同的例程在每个页面上创建连接即可）。

当然，在异常情况下，池连接可能会导致困难，在这种情况下您可能需要禁用它们。但除此之外，只要不管它，它就应该起作用。

Answer 6

我发现的关键是创建数据库连接需要多长时间。

对于跨越半个地球、连接速度较慢的 MSSQL Server，池化将显着提高应用程序的响应能力。

对于本地 MySQL 安装，您可能看不到显着差异。