最佳实践在.Net代码中重新共享IDbConnection或连接字符串/工厂

Question

我想知道在.Net应用程序中维护与数据库连接的最佳方法是什么（ADO.NET，但我想任何数据层的实践都应该相同）。我应该创建一个数据库连接并在我的应用程序中传播它，还是最好只需要传递连接字符串/工厂并创建一个ad-hoc连接。

据我所知，性能打击对于池并不重要，它允许我很容易从断开的连接中恢复（只是创建一个新连接）但是再一次连接对象是一个不错的，相对高级的抽象和创建每个操作的新连接（不是SQL命令，但是应用程序操作）会生成额外的重复代码，感觉就像浪费时间/资源（？）。

您如何看待这2个案例，他们的缺点/专业知识以及您在现实生活中使用哪种方法？

由于

Answer 1

我发现自己需要传递一个连接对象，所以我可以允许多个业务对象将自己保存到单个事务中的数据库中。

如果每个业务对象都必须为数据库创建自己的SQLConnection，那么事务将升级到分布式事务，我想避免这种情况。

我不喜欢将SQLConnection对象作为保存对象的参数传递，因此我创建了一个ConnectionManager来处理为我创建SQLConnection对象，跟踪SQLConnection对象的使用，以及在没有SQLConnection对象时断开连接。在使用中。

以下是一些代码作为ConnectionManager的示例：

public class ConnectionManager: IDisposable
{
    private ConnectionManager instance;

    [ThreadStatic]
    private static object lockObject; 
    private static Object LockObject
    {
        get
        {
            if (lockObject == null)
                lockObject = new object();
            return lockObject;
        }
    }

    [ThreadStatic]
    private static Dictionary<string, ConnectionManager> managers;
    private static Dictionary<string, ConnectionManager> Managers
    {
        get
        {
            if (managers == null)
                managers = new Dictionary<string, ConnectionManager>();
            return managers;
        }
    }

    private SqlConnection connection = null;
    private int referenceCount;
    private string name;


    public static ConnectionManager GetManager(string connectionName)
    {
        lock (LockObject)
        {
            ConnectionManager mgr;
            if (Managers.ContainsKey(connectionName))
            {
                mgr = Managers[connectionName];
            }
            else
            {
                mgr = new ConnectionManager(connectionName);
                Managers.Add(connectionName, mgr);
            }

            mgr.AddRef();
            return mgr;
        }
    }

    private ConnectionManager(string connectionName)
    {
        name = connectionName;
        connection = new SqlConnection(GetConnectionString(connectionName));
        connection.Open();
    }

    private string GetConnectionString(string connectionName)
    {
        string conString = Configuration.ConnectionString;
        return conString; 
    }

    public SqlConnection Connection
    {
        get { return connection; }
    }

    private void AddRef()
    {
        referenceCount += 1;
    }

    private void DeRef()
    {
        lock (LockObject)
        {
            referenceCount -= 1;
            if (referenceCount == 0)
            {
                connection.Dispose();
                Managers.Remove(name);
            }
        }
    }

#region IDisposable Members

    public void Dispose()
    {
        Dispose(true);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            DeRef();
        }
    }

    ~ConnectionManager()
    {
        Dispose(false);
    }

#endregion

}

以下是我将如何从业务对象中使用它：

public void Save()
{   
    using (ConnectionManager mrg = ConnectionManager.GetManager("SQLConnectionString")
    {
        using (SQLCommand cmd = new SQLCommand)
        {
            cmd.connection = mgr.Connection
            // More ADO Code Here
        }

        _childObject.Save(); //this child object follows the same pattern with a using ConnectionManager.
    }
}

我保存了一个业务对象，并且使用相同的连接对象也保存了它的所有子节点。当范围远离原始父级时，using语句将关闭连接。

这是我从Rocky Lhotka的CSLA框架中学到的一种模式。

基思

Answer 2

你真的不应该自己处理这个问题，因为有无数的工具可以为你做到。

如果你真的想自己做，那么请查看工作单元模式您可以在哪里管理连接/事务生命周期。你当然不想尝试在不同地方打开/关闭连接的凌乱水域中航行。

如果您决定让组件直接打开数据库连接，那么连接生命周期可能过于细粒度，导致单个用户操作的许多打开/关闭连接。

Answer 3

ADO.NET SQL Server提供程序自己进行连接池。您可以通过连接字符串中的 MinPoolSize 和 MaxPoolSize 来控制池大小。

Answer 4

在您的示例中要警惕的一件事是ASP.NET应用程序不应该使用ThreadStatic存储，因为线程可以重复使用，如果您不清理所有对象，最终会挂起连接周围。

在ASP.NET应用程序中，我会使用HttpContext.Items集合。您正在实现IDisposable，但我已经看到开发人员忘记调用Dispose或将代码放在using块中的情况。