3

私は非常に単純なASP.netプロジェクトを書いています。Linq2SqlDataContextを使用してストアドプロシージャにアクセスしています。コンストラクターに新しいDataContextを作成し、disposeに破棄するIDisposableクラスがあります。

可能な限り、次の内部でリクエストをグループ化します。

    using(var dc = new MyDataAccessClass())
    {
       //All the data requests in here
    }

    // Do stuff with the data here

したがって、コード全体でこれらのかなりの数が主にUserControlsにあり、開始ページ（またはマスターページ）のPageLoadで単一のDataAccessクラスを作成し、それをSessionに格納することが理にかなっているのではないかと考えていました。メモリ、およびすべてのUserControlsなどで参照し、PreRenderステージで破棄します。

これが私の質問です、これは悪い考えですか？例外やデバッグによってPreRenderの実行が停止するため、これにはデータベースへのいくつかのぶら下がっている接続が含まれると思います。たぶん、MasterPageのLoadをチェックして、そのセッション変数に何かがあるかどうかを確認し、ある場合はそれを破棄すると、ソートされます。

または、DBAがキーボードであなたを攻撃することなく、ページのライフサイクル全体でDataContextを共有するためのよりスマートな方法はありますか？

4

2 に答える 2

4

セッションはおそらく良い考えではありません - 並行性、切断された接続の回復などについて心配する必要があります。また、例外が発生した場合、PreRender ハンドラーが実行されないため、PreRender でコンテキストを破棄するアプローチは最適ではありません。

System.Web.HttpContext.Current.ItemsASP.NET の唯一のストレージであり、単一の要求の間だけ有効であり、実行中に ASP.NET 要求が異なるスレッド間で転送されるというまれな状況でも処理されます。

Application_EndRequestglobal.asax でイベントを使用して、接続を常に正しく破棄できます (エラーの後に EndRequest も呼び出されます)。

于 2012-11-05T11:36:10.027 に答える
3

ASP.NETでは、依存性注入フレームワークを使用して、要求ごとに1回作成するのが最善の策です。

たとえば、https ：//github.com/ninject/Ninject.Web.Common/wiki/Inrequestscopeを参照してください

于 2012-11-05T11:25:56.337 に答える