在静态方法中包装新的SqlConnection实例是不好的做法吗?

时间:2014-07-15 09:47:33

标签: c# static sqlconnection

我创建了一个可以从DataLayer调用的静态方法,以便获取数据。我意识到如果你正在为SQLConnection做一个Singleton是非常糟糕的,因为可能有并发用户,我有连接池来处理这个问题。

我已创建此方法static,而不是每次都初始化该方法。

  public static DataSet Fetch(String DataSet, String StoredProcedure, String SrcTable)
    {
        DataSet ds = new DataSet(DataSet);

        using (SqlConnection conn = new ConnectionClass().Connection)
        {
            try
            {
                using (SqlCommand cmd = new SqlCommand(StoredProcedure, conn))
                {
                    using (SqlDataAdapter adapter = new SqlDataAdapter(cmd))
                    {
                        adapter.Fill(ds, SrcTable);
                    }
                }
            }
            catch (SqlException ex)
            {
                throw ex;
            }
            catch (Exception ex)
            {
                throw ex;
            }
            finally
            {
                if (conn.State == ConnectionState.Open)
                    conn.Close();
            }

            if (DatabaseUtils.DataSetIsNotEmpty(ds))
                return ds;
        }

        throw new NoRowsReturnedException("Database has returned no rows");
    }

这种方法是否会在已部署的环境中中断?

3 个答案:

答案 0 :(得分:2)

方法很好,但不需要所有try / catch / finally。这就是"使用"确实。如果没有成功构造conn对象,更不用说你有潜在的空引用。

答案 1 :(得分:2)

如果您愿意,可以将此方法设为静态。例如,设计的问题在于您无法在测试中替换它。所有客户端代码都物理绑定到静态类。这是我通常在代码中避免的内容。

还有一个建议:不要处置ConnectionClass返回的连接。这样,ConnectionClass对象变为无效。相反,使整个ConnectionClass一次性使用,如下所示:

public class ConnectionClass : IDisposable
{
    private SqlConnection conn;

    private void Connect()
    {
        if (conn == null)
        {
            // connect
        }
    }

    public SqlCommand CreateCommand(string spName)
    {
        Connect();
        return this.conn.CreateCommand(StoredProcedure, spName);
    }

    public void Dispose()
    {
        if (conn != null)
        {
            conn.Dispose();
            conn = null;
        }
    }
}

通过这种方式,ConnectionClass负责建立和关闭连接。另外,从班级名称中删除Class - 它没用。

答案 2 :(得分:0)

我没有看到任何会破坏生产的东西。它是否是一个好主意取决于您的问题域以及您检索的数据如何与之相关联。

如果您所做的只是抓取结果集并将其吐在屏幕上或文件中,那么是的,请继续。您将结果的获取视为实用程序,在许多情况下与日志记录或数学函数不同。它快速,肮脏,并且用更少的努力完成工作。检索数据可能不一定是您的问题域的组成部分。它只是解决代码解决问题所需的功能。这方面的一个例子是为管理层建立一套报告。数据很重要但不是问题域的组成部分,因为您最多会执行聚合并吐出原始数据。

如果您的应用程序需要将结果的每一行都理解为对象并以更有意义的方式开始使用该数据,那么您可能希望将访问数据库视为一个实用程序,而不是将其作为问题域的组成部分。这是您想要开始查看Repository模式等内容的地方。您将采用更加面向对象的方法,因此不希望使用静态方法/类。这方面的一个例子是库存管理系统,其中处理系统中的各个项目是系统功能的组成部分。

问自己这些问题,你应该能够找到答案。从纯编码的角度来看,您的代码看起来很实用。