問題タブ [unit-of-work]

FluentNHibernate は初めてですが、この分野にも興奮しています。私は最近、前述を使用して新しい DAL の作業を開始し、リポジトリ パターンについて調べています。私はこのパターンの一般的な形式が気に入っており、このパターンを UnitOfWork パターンと組み合わせてセッション管理に使用したいと考えています。

興味がありますが、これは正しい方向ですか? UoW を使用して疑似シングルトン NHibernate セッションを作成する必要がありますか? この質問は、実際には NHibernate セッション管理のトピックに関連しています。私が調べた利用可能な UoW 実装がありますが、このライブラリを実装するために作業する必要があるのか​​ 、それとも自分自身を抽象化する必要があるのか​​ も不明です。

編集：

質問を再明確にするために：

FluentNHibernate 環境でリポジトリ パターンと共に UoW パターンを使用するのは一般的な方法ですか?

素人の言葉で言えば、データベースオブジェクトに関する作業単位は何ですか？私はデータベーステーブルをC＃クラスに変換する方法を研究していて、この用語に頻繁に出くわしますが、誰もがそれが何であるかをすでに知っている必要があるかのように説明しているようです。

Martin Fowler が「Unit of Work」パターンと呼んでいるものに似たものを設計して実装する必要があります。他の人がそれを「ショッピング カート」パターンと呼んでいると聞いたことがありますが、ニーズが同じであるとは確信していません。

具体的な問題は、ユーザー (および UI チーム) が、親オブジェクトが作成される前に、(データベース内の参照整合性制約を使用して) 子オブジェクトを作成して割り当てることができるようにしたいということです。今日、別のデザイナーと会い、2 つの代替アプローチを考え出しました。

a) まず、データベースにダミーの親オブジェクトを作成し、次にダミーの子とダミーの割り当てを作成します。負のキー (通常のキーはすべて正のキー) を使用して、データベース内の羊とヤギを区別できます。次に、ユーザーがトランザクション全体を送信すると、データを更新し、実際のキーを追加して調整する必要があります。

これにはいくつかの欠点があります。

• これは、インデックスに摂動を引き起こします。
• それらを持つ列の一意の制約を満たすために、何かを考え出す必要があります。
• 多くの既存の SQL と SQL を生成するコードを変更して、多くの WHERE 句にさらに別の述語を追加する必要があります。
• Oracle で主キーを変更することはできますが、それは困難です。

b) これらのリバース トランザクションに参加できるようにする必要があるオブジェクトと割り当ての一時テーブルを作成します。ユーザーが [送信] をクリックすると、実際のエントリが生成され、古いエントリが消去されます。

これは最初の方法よりもクリーンだと思いますが、それでもデータベース アクティビティのレベルが高くなります。

どちらの方法でも、ユーザーが送信要求またはキャンセル要求を実行する前にセッションが失われた場合、一時データを期限切れにする何らかの方法が必要です。

誰かがこの問題を別の方法で解決しましたか?

よろしくお願いします。

私は本格的な DDD を行っているわけではありませんが、リポジトリ パターンは魅力的であり、集約とルートの境界に沿ってリポジトリをセグメント化しようとしています。私は Entity Framework の上にリポジトリを実装しています。ここで ObjectContext は、エンティティへの変更を追跡し、SaveChanges が呼び出されたときに適切な SQL を生成するため、作業単位のスタイルを可能にします。

SaveChanges をいつ呼び出すかについて、リポジトリ内で 2 つの異なるアプローチに苦労しています。違いは、作業単位またはアクティブ レコード セマンティクスのどちらを採用しているかのようです。リポジトリ インターフェイスを次のように定義すると、次のようになります。

および IUnitOfWork になる

Add(T entity) の実装では、次の 2 つの選択肢があるようです。

また

前者の場合、リポジトリの Add メソッドが各操作で SQL を送信しています。後者の場合、呼び出し元のコードは、リポジトリから作業単位を取得し、適切と思われる場合に SaveChanges を呼び出します。これにより、作業単位が異なるリポジトリにまたがることができます (各リポジトリがその構築で同じ作業単位を取得するようにしています)。

私の直感では、2 番目のアプローチの方が柔軟です。作業単位パターンを採用するということは、呼び出しコードがリポジトリーから返されたエンティティーのプロパティーを単純に更新してから、UnitOfWork.SaveChanges を呼び出すという点で、エンティティーの更新が少し良くなることも意味します。

リポジトリ パターンを使用する場合、一般的にどちらのアプローチが好まれますか?

Linq to SQL の Repository パターンを実装する例はたくさんあるようです。それらのほとんどは IRepository と DI を備えています。Unit of Work を実装しているものと実装していないものがあります。SO と Google on Linq で検索して返された結果のほとんどを SQL リポジトリ パターンに読み込もうとしました。それにもかかわらず、私はまだ完全な解決策に出くわしていません。

私の読書から、以下に示すようにリポジトリパターンを実装しました：

_{（出典：sites.google.comのbaburajpb）}

DI を使用して、リポジトリが依存するインターフェイスを登録しています。

リポジトリ パターンの実装:

IRepository ジェネリック インターフェイス:

リポジトリ クラスは、以下のように IRepository の実装 (表示されていません) で実装され、DI が処理している IDataContextFactory に依存しています。

リポジトリは IoC を使用して消費されます。

リポジトリを使用するアプリケーション層で Linq から SQL への依存を避けるために、クエリの結果をビジネス オブジェクトのコレクションとして返しています。上記のシナリオは、MVVM パターンを使用している私の WPF アプリケーションで正常に動作します。Linq-SQL によって生成されたクラスに依存しない ViewModel aks Presenter クラスがあります。

データをデータベースに保存できるように、このパターンを拡張するにはどうすればよいですか。ビジネス オブジェクトをリポジトリに戻して保存したいと考えています。出来ますか？このようなシナリオで Unit of Work を実装するにはどうすればよいですか。

nhibernate と asp.net mvc でncommon フレームワーク ( http://code.google.com/p/ncommon/ ) を使用しています。作業単位パターンの実装は本当に気に入っていますが、ビューの遅延読み込みに問題があります。ncommon を使用してリクエスト パターンごとにセッションを実装する方法を探しているか、サポートする別のフレームワークを調べています。

1. linq から inhibernate
2. 作業単位パターン
3. ビューでの遅延読み込みをサポートするリクエスト パターンごとのセッション

どんなヒントでも大歓迎です。

次のコードのようなもので実装された作業単位パターンを見てきました。

そして、これらの各 HashSet にエンティティを追加するメソッドがあります。

コミット時に、UnitOfWork はエンティティごとにいくつかの Mapper インスタンスを作成し、架空の Mapper から Insert、Update、Delete メソッドを呼び出します。

このアプローチの問題点は、Insert、Update、Delete メソッドの名前がハードコードされているため、そのような UnitOfWork は単純な CRUD 操作しかできないように見えることです。しかし、次の使用法が必要な場合はどうでしょうか。

3 つの HashSet アプローチは失敗します。これは、挿入、更新、削除操作に対してのみ A エンティティと B エンティティを登録できたからですが、これらのカスタム操作が必要になりました。

したがって、常にリポジトリ操作をスタックしてから、すべてを実行できるとは限らないようですUnitOfWork.Commit();

この問題を解決するには？最初のアイデアは、メソッドのアドレスを保存できることです

UoWインスタンスでそれらを実行しますuow.Commit()が、すべてのメソッドパラメーターも保存する必要があります. それは複雑に聞こえます。

もう 1 つのアイデアは、リポジトリを完全に UoW 対応DoSomeNonSimpleUpdateHereにすることです。実行中の UoW があることを検出できるので、実行せずDoSomeNonSimpleUpdateHereに操作パラメータと「保留中」ステータスをリポジトリ インスタンスのスタックに保存します (明らかに保存できません)。 UoW は具体的なリポジトリの実装に依存するべきではないため、UoW のすべて)。そして、関連するリポジトリを UoW インスタンスに登録します。UoW が を呼び出すとCommit、トランザクションが開かれ、保留中のリポジトリごとに Flush() のようなものが呼び出されます。現在、Repository のすべてのメソッドには、UoW の検出と後で操作を延期するためのいくつかの要素が必要Commit()です。

簡単な質問は、保留中のすべての変更を UoW の複数のリポジトリに登録し、Commit()それらすべてを 1 つのトランザクションで登録する最も簡単な方法は何ですか?

以下についてアドバイスを求めています。

データベースと Web サービスの間で交換可能な DAL を作成する必要があります。私はC#とWPFで開発しています。

誰かが IUnitOfWork の適切な実装を見て、何らかの DI を使用して別の DAL を切り替えたり切り替えたりできるようにしていますか?

編集

それで、いくつかの読書をした後。リポジトリ パターンを使用することにしました。Rep パターンは IUnitOfWork を受け取ります。上は逆に読みます。また、スイッチのインまたはアウトの意味の例を次に示します。

したがって、IUnitOfWork に関するヘルプが必要だと思います。Web サービス リポジトリは扱いにくいものになります。では、ある種のトランザクションをどのように作成し、どのようにキューに入れるかなど.

最後にもう 1 つ、WPF 環境では複数のスレッドがデータベースに保存する可能性があるため、スレッドごとに独自の UnitOfWork を作成する必要がありますか? スレッドが別のスレッドの途中でコミットする可能性があるなど怖い.

「NHibernate と Unit of Work パターン」というタイトルのこの優れたブログを見ていて、asp.net mvc プロジェクトで UnitOfWork.Start を使用するのに最適な場所について質問があります。

私の SLN は次のプロジェクトに分類されます:-

私はインターフェースを持っています:-

具体的な実装があります

私の質問は、すべてのリポジトリ内のすべてのメソッドを using(UnitOfWork.Start()) でラップするか、それともより良いアプローチがありますか?

nHibernate、asp.net mvc を使用しています。