DbContextとDispose

Hiroaki SHIBUKI @hidori

@shinsukeoda その１メソッドは１つ上の「サービス層」に入れてますね＞じぶん 「会員情報の更新」的な。

Kazuhiko Kikuchi @kazuk

@hidori かといって型いっしょの物をこっちはMVCのModelBinderから出てきたオブジェクトで、こっちはDbから Fetchした奴でを人間が書き分ける仕事をするのはもっと嫌な結果を生むんじゃないかね

Hiroaki SHIBUKI @hidori

@kazuk レポジトリから出てきた/入れるブツは POCO 的に扱えばいいんじゃない？ プロパティ値の取得・設定以外に期待する動作ってなんかある？？

Kazuhiko Kikuchi @kazuk

@hidori むしろ期待しない動作が引き起こされる事があるんだわA とBにDB的な関連があり、ORマッパーが A.B を生やしましたよと ModelBinder から A.B がnullなインスタンスが生成されて、これをAddしてSaveするとBにはdeleteが行く

Hiroaki SHIBUKI @hidori

@kazuk それはなんかこー、もっと前段階で調整しておかないとダメくない？ (^^;

Kazuhiko Kikuchi @kazuk

@hidori んだども、上から下まで OR マッパーが作った型で通ってるから調整の必要な境界がはっきりしなくなるんだわ

Hiroaki SHIBUKI @hidori

@kazuk 数が多いと把握するの大変だけど。。。詰め替えると型が別物になるし、詰め替えのコストがモッタイナくて (^^;

Hiroaki SHIBUKI @hidori

最新の更新メソッド： public static void Update(Predicate<Hoge> predicate, Action<Hoge> update);

Kazuhiko Kikuchi @kazuk

@hidori 商品と買ったお客のリレーションシップを追加してモデルに反映したとたんに商品情報更新時にリレーションシッププロパティ経由でお客が消えるという事故を目撃した人なので、そこのコストは払うべきと思いますよ

Hiroaki SHIBUKI @hidori

@kazuk え。商品情報の削除時じゃなく？？？それでもすごいと思うけどｗ

Kazuhiko Kikuchi @kazuk

@hidori リレーションシッププロパティにnull入れてSaveは関連するものを消す動作になりまする

neuecc @neuecc

@kazuk @hidori なるる、それをHttpContext.DisposeOnPipelineCompletedに突っ込むとかは、ダメ？

Kazuhiko Kikuchi @kazuk

@neuecc @hidori 保険としてはアリ、明示的にDisposeするコードを書きたいから書くけど( Dispose は何度呼んでも良い事になってるので、入れとく事もある

Hiroaki SHIBUKI @hidori

@neuecc @kazuk DB接続がいつダメになるかは保証ないからね。DBアクセスダメになったところで、特にリカバリとかやらない感じならページリクエストの単位でもいいのでは。

neuecc @neuecc

@kazuk @hidori どもですー。安全策は取りたいので、RepositoryをIDisposableにする+DisposeOn...に入れておく、な方向でとりまやってみます。

Hiroaki SHIBUKI @hidori

うーん、やっぱりそっちに戻そうかなぁ (^^; RT @neuecc @kazuk @hidori どもですー。安全策は取りたいので、RepositoryをIDisposableにする+DisposeOn...に入れておく、な方向でとりまやってみます。

Hiroaki SHIBUKI @hidori

あ。static やめても using まみれにならないカタチ思いついたｗ RSS フィードのやつで実験してみよー

Hiroaki SHIBUKI @hidori

using や try ~ catch って、１個のスコープに大量には書きたくないよね

Kazuhiko Kikuchi @kazuk

@hidori SqlConnectionと SqlCommand 6個、SqlTransaction 、SqlDataReader のusingとConnectionとReaderのCloseがtry finally というてんこ盛りなコードとか嫌ですわぁ（実在する

Hiroaki SHIBUKI @hidori

@kazuk なるほどｗ その更新が全面的に許容できないならトリガーで防御？ しかし、そーするとテストデータ消す時とか少し手間か。

Kazuhiko Kikuchi @kazuk

@hidori そこでは、そもそもORマッパーにリレーションシッププロパティを作らせないという解になりましたわ（危ない機能は切る

Hiroaki SHIBUKI @hidori

@kazuk そっち方向でコストを払ったってのね。一律に何がいい悪いとも言えないトコか。

Kazuhiko Kikuchi @kazuk

@hidori 善し悪しはさておき ORマッパーのオブジェクトを余り遠くに持ち出さない事が重要かと。View への表示内容に整形結果を作る時にプロパティに書き戻されてコード値文字列のはずのカラムに表示用文言がSaveされたとかいう笑い話もあるし

Hiroaki SHIBUKI @hidori

@kazuk 詰め替えするならなるべく下でやるか、ホントの表層まで持ち越すかかなぁ。層間で何回も。。。ってのは避けたい。

Kazuhiko Kikuchi @kazuk

今の自分の立ち位置的には ORマッパーの存在は事故原因になるか事故防止のコストを払うとメリットが帳消しになるぐらいの代物でして…（Code Firstはedmx無いからT4で舐めて事故防止コード生成とかできないから気をつけろよ