將新的SqlConnection實例包裝在靜態方法中是不好的做法嗎？

Question

我創建了一個可以從DataLayer調用的靜態方法，以獲取數據。 我意識到，如果您為SQLConnection執行Singleton是非常糟糕的，因為可能會有並發用戶，並且我會由連接池來處理。

我已經靜態創建了此方法，而不必每次都初始化該方法。

  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");
    }

這種方法會破壞已部署的環境嗎？

Answer 1

該方法很好，但是不需要所有try / catch / finally。 這就是“使用”的作用。 更不用說如果conn對象未成功構建，則可能具有空引用。

Answer 2

如果願意，可以將此方法設置為靜態。 設計的問題是，例如，您不能在測試中替換它。 所有客戶端代碼在物理上都綁定到靜態類。 我通常在代碼中避免這種情況。

另一建議：不要處理由ConnectionClass返回的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沒有用。

Answer 3

我看不到任何會破壞生產的東西。 一個好主意取決於您的問題領域以及您檢索的數據如何與之相關。

如果您要做的只是獲取結果集並將其分散在屏幕上或文件中，請繼續。 您將結果的獲取視為實用程序，在許多情況下與日志記錄或Math函數沒有什么不同。 它快速，骯臟，並且可以輕松完成工作。 檢索數據可能不一定是您的問題域所必需的。 這只是解決代碼所要解決的問題所需的功能。 這樣的一個例子是建立一組管理報告。 數據很重要，但並不是問題域不可或缺的，因為您正在執行聚合並最多吐出原始數據。

如果您的應用程序需要將結果的每一行理解為一個對象，並以更有意義的方式開始使用該數據，則您希望將訪問數據庫的過程減少為一種實用工具，而應更多地視為問題域的組成部分。 這是您要開始查看“存儲庫模式”之類的地方。 您將采用一種更加面向對象的方法，因此將不希望使用靜態方法/類。 一個示例是庫存管理系統，其中處理系統中的單個項目是系統功能不可或缺的部分。

問問自己這些問題，您應該就能找到答案。 從純粹的編碼角度來看，您的代碼似乎可以正常工作。