1

私のニーズのほとんどを処理する Sql ヘルパー クラスを作成しました。

その中に、次のように SQL ステートメントを実行して SqlDataReader を返す関数があります。

public static SqlDataReader ExecuteCommand(string cmdText, bool useParameters)
{
    using (var sqlConnection = new SqlConnection(_connectionString.ConnectionString))
    {
        sqlConnection.Open();
        using (var sqlCommand = new SqlCommand(cmdText, sqlConnection))
        {
            if (useParameters && SqlParameterCollection.Count > 0)
            {
                sqlCommand.Parameters.AddRange(SqlParameterCollection.ToArray());
            }

            using (var sqlDataReader = sqlCommand.ExecuteReader())
            {
                return sqlDataReader;
            }
        }
    }
}

これに関する問題は、明らかに、開いている接続を必要とする sqlDataReader を返すという事実と、接続が閉じられているという事実です。

代わりに SqlDataAdapter を返すことを検討しましたが、次のスレッドSqlDataAdapter vs SqlDataReaderを読んだ後、データの量がまったくわからない場合に、すべてのシナリオで使用される一般的な関数としてはあまり良い考えではないように思えますロードすることになっています。

だから... 良い代替案は何ですか?

頭のてっぺんから考えられる唯一のことは、SqlDataReader の行を循環してyield return IEnumerable<IDataRecord>.

これを達成するためのより良い方法はありますか、それともほとんどそれですか?

4

1 に答える 1

3

を使用できますCommandBehavior.CloseConnection。これにより、クロージャーが呼び出し元にオフロードされますが、usingこれにより、コードが呼び出し元のリーダーに正しく依存するようになります。

個人的には、このタイプの依存関係を最小限に抑え、マテリアライゼーション コードをできるだけ DB コードに近づけるようにします。実際には、呼び出し元が未加工のリーダーを必要とするケースはそれほど多くありません。少なくとも、そうであってはなりません。次のようなことができるように、「dapper」や ORM などのツールを使用することを強くお勧めします。

return connection.Query<T>(cmdText, args).ToList();

これにより、発信者が物事を混乱させるための多くの場所が残されません。

于 2013-11-04T16:47:22.893 に答える