HTTPはステートレスです。作業単位はサーバー側にのみ存在します。 'Load'をクリックすると、UOWはレコードを取得してビューモデルにマップするだけです。 「保存」をクリックすると、サーバの負荷を超えてブラウザで編集してサーバに戻すのではなく、サーバにアクセスしたときに作業単位が開始されます。
実装では、あなたのメモリ(あなたの場合ASP.Netセッションオブジェクト)にISessionを保持するべきではありません。メモリと管理されていないADNリソースを使い尽くす確実な方法です。いくつかの人々がbegin_requestでHTTPコンテキストにISessionを関連付け、end_requestで処理することを選択するいくつかのUOWの例がありますが、もちろんもっと細かいことはできますが、それ以上は決して存在しません。
シンプルなシステムでは、 '保存'を押すと、ID(隠しフィールドかどうか)を使用してデータベースから製品を引き出し、Request.Formからプロパティを設定してから更新する必要がありますデータベース。
並行性については、あなたは、保存を打ったとき
<input type="hidden" name="version" value="12"/>
はその後、あなたがデータベースから製品を引っ張り隠しフィールドにタイムスタンプまたはインクリメントバージョンを記録した場合のRequest.Form試合でバージョン番号が保存していることを、確認し、最後に取得してからデータが変更されたことをユーザーに戻さない場合は、続行しますか? NHibernateはtimestamp/versionフィールドを持っているので、実際にDBにヒットしたときに比較が行われます。つまり、Updateのwhere句が当てられます。
もっと精巧で洗練された方法がありますが、通常、あなたはasp.netセッションオブジェクトにISessionを張ってはいけません。
ウェブアプリケーションについては考えていません。私はwinformのアプリケーションについて不思議です。申し訳ありませんが、私は私の質問でそれを指定していない – codemnky
私の悪い、あなたのアプリケーションの起動時に終了、終了時にあなたのセッションを作成します。恐らくあなたのDB操作はスレッドではなく、これはうまくいくはずです。あなたが挑戦するならば、シングルトンマネージャを使用してください。 –
アプリケーションの存続期間中に1つのセッションを作成することは、ほとんどのnHibernateの専門家には推奨されません。 例外がスローされるか、トランザクションをロールバックする必要がある場合、キャッシングや潜在的な問題に関連するメモリー使用の問題があると私は考えています。 –