そういえばDbContextっていつDisposeするのが解なのでしょうか。Repositry Patternの例とか、フィールドに抱えてスルーが多い感で、そもそもDbContextってDisposeとかドーデモイイ系でしょうか?(その辺全然知りません)
2012-09-12 11:52:59Per Request で DbContext が作成されるようにして、Application_EndRequest で DbContext が作成されていたら Dispose(ドヤァ
2012-09-12 11:55:21@neuecc DbContext との繋がりをいつまでも持ってるのは諸刃の剣だと思うんで、僕は原則 Repository に生やすメソッドは static です。
2012-09-12 11:56:44@neuecc 実際のところは Dispose しなくても問題なさそうですけどね。1 つの DbContext を長時間使いまわしてたら逆に死にます
2012-09-12 12:00:09@shibayan @neuecc コネクションプールがあるから生成・破棄のコストは心配しなくていい反面、たまーに腐ったコネクションを引いてしまうリスクがあります。
2012-09-12 12:01:15@hidori @neuecc 自分の場合 interface IHogeRepository : IDisposable で上から Dispose 呼ばれた時に Dispose するようにしていますよ
2012-09-12 12:01:55@kazuk @neuecc 短い範囲でなら Repository を using でもいーと思うんだけど、短いんならレポジトリメソッド自体 static にして、その中で dbcontext を using のが話速いんじゃないかと。
2012-09-12 12:05:28SQL Azure に対するクエリがこけた時は接続からやり直すことになるし、フェデレーションかかった仮想テーブルに対するクエリ実行のなんやらかんやらも Repository までで隠ぺいしときたいので、今の状況に落ち着いてます>じぶん
2012-09-12 12:06:49@hidori @shibayan 長時間というのは、1リクエストどころじゃなく長期、でしょうかー。DbContext自体はクエリ一個につきOpen/Closeでコネクションをプールに戻す・取り出しますよね。「面倒くさい」「DbContext自体の生成のコスト」かなあ。考慮点。
2012-09-12 12:08:28@hidori @neuecc 更新系のトランザクション範囲を複数のリポジトリにまたがって伸ばす必要無いならそれでOKだと思われるけど、トランザクション範囲はたいがいリポジトリをまたがる
2012-09-12 12:08:39@neuecc SignalR の Hub で 1 時間以上使ってた時、意味の分からないエラーが頻発して俺が死にました(何
2012-09-12 12:09:17ASP .NET MVCのControllerはIDisposableなんだからちゃんとDisposeの連鎖関係をつなげていけば問題にはならんはず http://t.co/S0nTE6jD
2012-09-12 12:10:09@kazuk @neuecc 更新系トランザクション範囲を複数>そなんだけど、もっと上流まで持ち越すのも抵抗があって。。。ビュー作ってビューの更新にしえ逃げてるw
2012-09-12 12:10:50@neuecc @shibayan 長時間>1個のコンテキストで複数のページ処理とかはありえないので、1回の接続で複数回のクエリ・更新実行するようなイメージです>じぶん
2012-09-12 12:12:38リポジトリの1メソッド内でトランザクション完結したいなー。複数リポジトリ跨るのは、なんか単にORマッパーのDAO になってる感。自分的にはリポジトリはもっと大きい範囲のイメージがある。EF 使ってないから話題とずれてるかもだけど
2012-09-12 12:17:11SQL Azure でなくても、DB がフェールオーバーした時はやっぱりアプリレベルでクエリのリトライ必要な時あるし。
2012-09-12 12:18:16リポジトリの1メソッド内でトランザクション完結したいなー>同感。でも、異なるデータソースに所属する複数のレポジトリに対するトランザクションもありますからねー 会員管理が外出しとか
2012-09-12 12:20:19@hidori なるほど!確かにそうですね。でも上の層が呼び出すのはそれもひっくるめた1メソッドが嬉しいなーと思ってます。
2012-09-12 12:23:18