NHibernateセッションに切断オブジェクトをアタッチする。ベストプラクティス？

Question

私のリポジトリはUnitOfWorkモデルで動作します。検索や永続のいずれの操作も、IDisposableUnitOfWorkトークンオブジェクトの範囲内で実行する必要があります。トークンオブジェクトの背後には、要求された作業を実行するSessionが関連付けられています。だから、基本的なパターンは次のとおりです。

using (var uow = repo.BeginUnitOfWork()) 
{ 
    try 
    { 
     //DB operations here; all repo methods require passing in uow. 
     ... 
     repo.CommitUnitOfWork(uow); 
    } 
    catch(Exception) 
    { 
     repo.RollbackUnitOfWork(uow); 
     throw; 
    } 
} 

私も毎回すべて、この足場を実装する必要性を軽減、あなたはこの枠組みの中で実行されるラムダまたはデリゲートを指定することができ、いくつかのラッパー・メソッドを実装しました。

私が抱えている問題は、このモデルを使用すると、コードがUnitOfWork内のNHUtil.Initialize()を使用して、ユーザーが必要としていることを「知って」いることがわかります。 UOWが使用ブロックの最後に配置されると、PersistentBagsに関連付けられたセッションは閉じられ、評価されません。前向きなものをすべて積み重ねることは必ずしも実現可能ではないし、遅延ロードORMの目的を破るようなものであるので、私はAttach()メソッドを実装しています。

ここに質問があります。組み込みのISession.Attach()メソッドがない場合は、オブジェクトを新しいセッションに関連付けることを推奨している3つのメソッドがあります。仕事を終わらせるベストプラクティスはどれですか？

A：

if(!Session.Contains(domainObject)) 
    Session.Update(domainObject); 

B：

Session.Merge(domainObject); 

C：

Session.Lock(domainObject, LockMode.None); 

Answer 1

D：上記のなし。あなたのUOWをあまりにも短く保つことによってレイジーローディングを効果的に無効にし、レイジーローディングORMの目的を無効にします。切断されたオブジェクトを通常の操作として再関連付けする必要があるという事実は、作業単位の境界が間違っていることを意味します。

マージ、更新、ロックはすべて異なる目的を持っています。あなたの現在のアーキテクチャに悩まされているなら、おそらくロックはあなたが望むものです。

• 更新 - 変更されたオブジェクト
• ロックを関連付ける -
• マージをそのままオブジェクトを関連付ける - オブジェクトが 現在のセッションに存在する場合、それは、マージされたオブジェクトからの変更と 、 に更新され、それ以外の場合はですロックと同じです。