0

カスタム データ アクセス レイヤーを作成することは、次の場合を除き、あまり良い考えではないことを私は知っています。ただし、各メソッドが次のようなカスタム データ アクセス レイヤーを使用するレガシー コードを維持しています。

    using (SqlConnection cn = new SqlConnection(connectionString))
{
    using (SqlDataAdapter da = new SqlDataAdapter("sp_select_details", cn))
    {
        using (DataSet ds = new DataSet())
        {
            da.SelectCommand.Parameters.Add("@blind", SqlDbType.Bit).Value = blind;
            da.SelectCommand.CommandType = CommandType.StoredProcedure;
            da.SelectCommand.CommandTimeout = CommandTimeout;
            da.Fill(ds, "sp_select_details");
            return ds;
        }
    }
}

したがって、使用法は次のようになります。

    protected void Page_Load(object sender, EventArgs e) {
    using (Data da = new Data ("SQL Server connection string")) {
        DataSet ds = da.sp_select_blind_options(Session.SessionID); //opens a connection
        Boolean result = da.sp_select_login_exists("someone");//opens another connection
    }
}

Microsoft の Enterprise Library を使用すると、セットアップと破棄、つまりメソッド呼び出しのたびに SQL Server に接続する必要がなくなるのではないかと考えています。私はこの考えで正しいですか？

4

3 に答える 3

0

はい、それは間違いなくあなたの時間を節約しますが、あなたはパフォーマンスと柔軟性の面で支払うでしょう。

したがって、カスタムを作成することDataLayerも、パフォーマンスと柔軟性を得るのに非常に良いアイデアです。

あなたがレガシーコードについて話していることを考えると、それは機能すると思いますが、コードに新鮮なものがあるという理由だけで、それを現代的なものに変更することはありません（ただしパフォーマンスは低下します） 。

堅実で実行可能なDataLayerものは、レガシーコードに実装する必要のある他の新しいテクノロジーよりも優れた選択肢です。

要するに、あなたがそれをする本当に深刻な理由がある場合にのみそれを変更してください。他の誰かが書いたコードを理解するのは常に難しいので、あなたが物事を変更する意思があることは理解していますが、古いレガシーコードを変更しないことがプロジェクトの最良の選択であることが非常に多いと信じています。

幸運を。

于 2012-04-05T21:13:22.657 に答える
0

私は過去に Enterprise Library を非常にうまく使用しており、Enterprise Library は厄介な詳細の一部を隠していましたが、基本的には、例で示したのと同じコードを内部で使用していました。

@tigran が言うように、基本的な問題がない限り、既存のコードベースを変更しようとすることはお勧めしません。

于 2012-04-05T21:19:41.370 に答える
0

はい、デフォルトで接続プールがオンになります。アプリケーション ドメインは基本的に接続のリストを維持し、接続を作成するための呼び出しを発行すると、存在する場合はプールから未使用のものが返され、存在しない場合は作成されます。

そのため、接続 cn が using ステートメントで範囲外になり、get が破棄されると、実際にはプールに戻り、次の要求の準備が整い、さまざまな最適化パラメーターに基づいてそこでぶらぶらします。

詳細については、Google ADO 接続プーリングを参照してください。

于 2012-04-05T21:21:00.857 に答える