問題タブ [unit-of-work]

NHibernate を使用してリポジトリ パターンをセットアップしています。基本クラスは次のようになります。

ご覧のとおり、コンストラクターを介して (StructureMap を使用して) 作業単位を設定できるようにしています。次のように、ASP.NET Web サービスにリポジトリ オブジェクトを設定しています。

お察しのとおり、私の問題は、設計上、作業単位のライフサイクルを制御できなくなったことです。以前は、作業単位を状況依存オブジェクトにして、リポジトリは次のような方法でそれへの参照を取得していました。

この以前の設計では、using ステートメント内で UnitOfWorkFactory から作業ユニットを作成することで、コード内の作業ユニットのライフ サイクルを制御できました。もっと多くの作業を IoC コンテナーの手に委ねようとしていましたが、実際には一歩後退したと思います。どちらの実装についてもどう思いますか?

たくさんの記事を読んだ後でも、リポジトリとやり取りするときの Unit of Work パターンの責任についてまだ確信が持てません。

リポジトリは集約ルート エンティティの読み込みと保存を担当するため、次のコード例を検討してください。

作業単位インターフェースは、次のメソッドで定義されます。

リポジトリが非常に単純な SQL マッパーを使用して実装されているとします。そのため、FindByName には ARoot を返すための直接的な SQL が含まれています。Save の実装は次のようになります。

Unit Of Work Commit コードは、エンティティを DB にマップするために必要なすべての SQL を構築しますか?

質問2）

集約ルートを作業単位に追加する場合、作業単位はルートとその子エンティティを永続化する責任がありますか?それともリポジトリの Save メソッドで変更されたエンティティを作業単位に追加する必要がありますか? 例えば

または...代わりに

作業ユニットは集約ルートのみを処理し、コミット時に変更セット内の各オブジェクトのリポジトリ Save メソッドを呼び出し、SQL マッピング コードを保持してリポジトリ内のエンティティを永続化し、最初のコード例を次のように変更しますか?

ありがとう、

ジェームズ

責任者は誰か

---

MVC アーキテクチャで作業単位を開始および終了する責任は誰にありますか?

いくつかの制約に基づいて複数のテーブルで挿入と更新が行われる特定のシナリオがあります。そのため、これらのシナリオでトランザクションスコープを使用するのは自然なことです。これで、リポジトリレイヤーとサービスレイヤーができました。サービスレイヤーはリポジトリとUIを仲介し、永続的に無知です。現在、サービス層またはリポジトリ層のいずれかでトランザクションを使用する場所がわかりません。ORMを使用していません。私はまた、そのようなシナリオの作業単位パターンについて提唱する人々を見てきました。私の現在のシナリオに合った作業単位パターンに関する例はありますか？私が見たすべての例はORMSを使用しています。

ありがとう、

以前のプロジェクトに似た新しいプロジェクトを開始しようとしています。古いデザインをコピーすることはできますが、古いデザインに満足しているわけではありません。

これは、バックエンドに Entity Framework を備えた .Net 3.5 (Winforms MDI) の上に構築された「標準的な」ビジネス システム (販売、棚卸、倉庫管理など) です。

すべてのフォームはベースフォーム (Windows.Form を継承) から継承します。このフォームは、最初の呼び出しで新しい ObjectContext をインスタンス化する ObjectContext というプロパティを公開します。これはかなり良い UnitOfWork を構成し、すべてのデータアクセスを各フォームで分離しています。

でも。

すべてのクエリと一般的な CRUD を「貧しい人々 のリポジトリ」にカプセル化しました。これらのリポジトリは、ObjectContext のプロパティとして公開されます。

したがって、フォームにバインドして注文する場合は、OrderLinesGrid = ObjectContext.OrderRepository.GetOrderLinesByID(orderID) を呼び出します。

OrderRepository は、このように、フォーム用に作成された objectcontext への参照を取得します。

(私の部分的な ObjectContext クラスで)

これについて私が気に入らない点は次のとおりです。

1. リポジトリへの呼び出しは、ObjectContext を通じて行われます。したがって、クエリと必要なデータアクセスレイヤーの間の抽象化が得られません。

2. ドメインの新しい型ごとに、ObjectContext にプロパティを作成する必要があります

OrderRepository への呼び出しは、ドメイン オブジェクトを返すだけで、それがどのように保持されるかを気にする必要はありません。また、各リポジトリに独自の ObjectContext を持たせることはできません。これは、Country を Order.Country プロパティに参照するときにオブジェクトをアタッチおよびデタッチする必要があるためです。

このデザインに関するアイデアやフィードバックをいただければ幸いです :)

(Wall Of Text で申し訳ありません... :) )

概要

Winfor アプリケーションで依存性注入を使用すると、多数のリポジトリ コンテキストが作成されます。私がこれを使用している方法が正しいか間違っているか、または一般的な慣行が何であるかはわかりません。

詳細

過去 6 か月間、私は Unit OfWork パターンとリポジトリ パターンを実装する ASP.NET MVC アプリケーションを作成してきました。これに加えて、私はこれらすべての Web アプリケーションで依存性注入を使用しており、ある程度の成功を収めています。

これは、私のリポジトリを配線する例です。

わかりました-うまくいきます。ここで注意すべき主なことは、

• ライフサイクルが Web シナリオの正しいものであると仮定しています。
• コンテキストは、Web サーバーにヒットする REQUEST ごとに 1 回だけ存在します。

キュール。

さて、私の WinForm アプリケーションでは、最初に 1 つの Unit Of Work オブジェクトを作成し (依存性注入はまだありません)、その赤ちゃんをすべてのサービス (そしてリポジトリ) に渡し続けました。

この win アプリケーションでは、解析する必要があるすべてのテキスト ファイルを見つけるために DB にアクセスします。(例: 25 ファイル)。次に、ファイルごとに新しいパーサーを作成し、各行を読み取り、解析されたデータを db テーブルにチャックします。罰金。

問題は、このコンテキストがすべてのパーサー間で共有されていたため、ショップ全体で深刻なエラーが発生していたことです。

それで、いくつかの依存性注入を追加し、上記のレジストリ コードを使用します。同じことです - 重大なエラーがたくさんあります。これは、単一のスレッド -> winform に対して 1 つのコンテキストが再度作成されたためです。

そのため、コンテキストのレジストリを次のように調整しました:-

そのため、WinForm アプリケーションの場合、ライフサイクルが設定されなくなりました。これにより、約160程度のコンテキストが作成されたと思います! （しかし、実際にはエラーでもありませんでした）。

したがって、これが正しい方法であるかどうかはわかりません。

したがって、私のアプリでは、実際には 25 の異なるタイマーが作動し、ファイルを .. たとえば .. 10 秒ごとにチェックします。新しいデータがある場合は、それを解析します。それ以外の場合は、10 秒後に戻ってきてください。

解析されるこれらのファイルのそれぞれは、独自のスレッドである必要がありますか? 次に、スレッドごとにコンテキストを作成しますか? （これはWebシナリオに似ていると感じています）。それともこれでいいの？私はそれが多くのコンテキストであることを知っていますが、各コンテキストはデータベースへのライブ接続を意味するものではありません..そして接続プールでは、これは実際には問題になりません.

非常に多くのコンテキストがある理由は、次のコードのためです...（これらは、いくつかのリポジトリクラスの個別のコンストラクターです...）

メインのサービスについては...

そのため、サービスには UoW が必要で、各リポジトリにも 1 つ必要です。つまり、それぞれに対して新しいものが作成されます。

私はこれを正しく構造化していないと確信しています...

どんな提案でも心から感謝します！

ここで説明されているように、Unit of Work/Repository パターンを実装しようとしています: http://blogs.msdn.com/adonet/archive/2009/06/16/using-repository-and-unit-of-work- pattern-with-entity-framework-4-0.aspx

これには、各リポジトリが IUnitOfWork 実装を受け入れる必要があります。たとえば、IUnitOfWork インターフェイスを追加するために部分クラスで拡張された EF データコンテキストです。私は実際には4.0ではなく.net 3.5を使用しています。私の基本的なデータ アクセス コンストラクターは次のようになります。

ここまでは順調ですね。

私がやろうとしているのは、Unity Framework を使用して依存性注入を追加することです。

Unity で EF データ コンテキストを作成するのは冒険でした。コンストラクターの解決に問題があったためです。最終的に私が行ったことは、新しいオーバーロードされたコンストラクターを使用して部分クラスに別のコンストラクターを作成し、それを でマークすること[InjectionConstructor]でした。

（接続文字列をベースオブジェクトに渡す必要があることはわかっています。これは、すべてのオブジェクトが正しく初期化されるまで待つことができます）

したがって、この手法を使用すると、エンティティ フレームワーク オブジェクトを次のように IUnitOfWork インスタンスとして問題なく解決できます。

偉大な。ここで行う必要があるのは、DataAccessLayer のリポジトリ オブジェクトへの参照を作成することです。DAL はインターフェイスを知る必要があるだけなので、Unity Resolve ステートメントの一部としてインスタンス化する必要があると推測しています。 IUnitOfWork インターフェイス。

以前は、Repository コンストラクターに db 接続文字列を渡すだけで、ローカルの Entity Framework オブジェクトを作成し、Repository メソッドの有効期間だけ使用していました。これは、Unity Resolve ステートメント中に Entity Framework インスタンスを IUnitOfWork 実装として作成するという点で異なります。これは、リポジトリのコンストラクターに渡す必要があるインスタンスです。それは可能ですか?

リポジトリをプロパティにして依存関係としてマークできるかどうか疑問に思っていますが、それでも、DAL が解決されている IUnitOfWork オブジェクトを使用してリポジトリを作成する方法の問題は解決しません。

このパターンを正しく理解しているかどうかはわかりませんが、それを実装するための最良の方法についてアドバイスを喜んで受けます. 全体が逆さまになっている場合は、教えてください

これについての私の最初の質問は誰も好きではありませんでした： Unit of Work/RepositoryパターンでUnityを使用してEntityFrameworkオブジェクトを作成する

だから私はそれを眠りにつく/生きる意志を失うことなく読めるものに言い換えることができました。

コンストラクターで2つのインターフェイス（IUnitOfWorkとIRealtimeRepository）を使用するオブジェクトDataAccessLayerを作成しています。

現在、IRealtimeRepositoryを実装するためのコンストラクターは、IUnitOfWorkパラメーターも取ります。

Unityコンテナのセットアップで、次の2つの実装を追加します。

Unityは、IUnitOfWork（実際にはEntity Frameworkデータコンテキスト）の2つの新しいインスタンスを作成します。1つはDataAccessLayerコンストラクター用で、もう1つはDemoRepositoryコンストラクター用です。

これは作業単位パターン用であるため、同じインスタンスを再利用することが非常に重要です。何か案は？以前に同様の質問があったが、受け入れられなかったようです

互いにデッドロックしている 2 つの SQL ステートメントを説明する次のデッドロック グラフがあります。この問題を分析し、SQL コードを修正してこれが起こらないようにする方法がわかりません。

主なデッドロック グラフ

代替テキスト http://img140.imageshack.us/img140/6193/deadlock1.png クリックすると大きな画像が表示されます。

左側、詳細

代替テキスト http://img715.imageshack.us/img715/3999/deadlock2.png クリックすると大きな画像が表示されます。

右側、詳細

代替テキスト http://img686.imageshack.us/img686/5097/deadlock3.png クリックすると大きな画像が表示されます。

生のデッドロック スキーマ xml ファイル

ここをクリックして xml ファイルをダウンロードします。

テーブル スキーマ

代替テキスト http://img509.imageshack.us/img509/5843/deadlockschema.png

LogEntries テーブルの詳細

代替テキスト http://img28.imageshack.us/img28/9732/deadlocklogentriestable.png

接続済みクライアント テーブルの詳細

代替テキスト http://img11.imageshack.us/img11/7681/deadlockconnectedclient.png

コードは何をしていますか？

同時にいくつかのファイル (たとえば、この例では 3 つとしましょう) を読み込んでいます。各ファイルには異なるデータが含まれていますが、同じタイプのデータが含まれています。次に、データをLogEntriesテーブルに挿入し、(必要に応じて)ConnectedClientsテーブルに何かを挿入または削除します。

これが私のSQLコードです。

現在、各ファイルには独自のUnitOfWorkインスタンスがあります (つまり、独自のデータベース接続、トランザクション、およびリポジトリ コンテキストがあります)。したがって、これは、データベースへの3つの異なる接続がすべて同時に発生していることを意味すると想定しています。

最後に、これはEntity Frameworkリポジトリとして使用していますが、この問題について考えるのをやめさせないでください。

プロファイリング ツールを使用するとIsolation Level、Serializable. ReadCommitedとも試しましReadUncommitedたが、どちらもエラーです:-

• ReadCommited： 同上。デッドロック。
• ReadUncommited: 別のエラー。なんらかの結果が返されることを期待していたが、何も得られなかったという EF 例外。LogEntryId これは期待されるIdentity ( ) 値であると推測してscope_identityいますが、ダーティ リードのために取得されません。

助けてください！

PS。ところで、それはSql Server 2008です。

---

アップデート #2

Remus Rusanuの更新された返信を読んだ後、他の誰かがさらに助けてくれるかどうかを確認するために、もう少し情報を提供できると感じました.

EFダイアグラム

代替テキスト http://img691.imageshack.us/img691/600/deadlockefmodel.png

さて、Remus は提案します (そして、彼は EF に慣れていないと言っています)...

パズルの最後のピースである、左ノードが PK_ConnectedClients に持っている原因不明のロックは、InsertOrUpdate の EF 実装によるものだと思います。おそらく最初にルックアップを行い、ConnectedClients と LogEntries の間で宣言された FK 関係のために、PK_ConnectedClients をシークし、シリアライズ可能なロックを取得します。

面白い。上記のように、左側のノードがロックされている理由がわかりませんPK_ConnectedClients。わかりました、そのメソッドのコードをチェックしてみましょう....

うーん。それは単純なAddObject（別名挿入）またはAttach（別名更新）です。参照なし。Sql コードは、ルックアップのヒントもありません。

わかりました...他に2つの方法があります...おそらくそれらはいくつかのルックアップを行っていますか?

ConnectedClientRepository で ...

いいえ -> また、基本的なように。

ラッキーラストメソッド？うわー..これは面白いです....

したがって、上記を見て、削除したいレコードのインスタンスを取得し、存在する場合は削除します。

だから..そのメソッド呼び出しをコメントアウトすると、最初のロジックの方法でこのSO投稿の一番上まで...どうなりますか?

できます。うわー。

また、どちらかSerializableまたはどちらでも機能します-メソッドRead Commitedを呼び出さない場合は両方とも機能します。Delete

では、なぜその削除メソッドがロックされるのでしょうか? select ( with serializable) がロックし、デッドロックが発生するためですか?

ではread committed、削除への呼び出しが同時に 3 回発生する可能性はありますか。

• 1 つ目は、データのインスタンスを取得します。
• 2 番目 (および 3 番目) は、同じデータの別のインスタンスを取得します。
• さて、1回目の削除です。大丈夫。
• 2番目の削除..しかし、行がなくなった..したがって、予期しない行数（0）に影響を与えるという奇妙なエラーが発生します。<== 0 個のアイテムが削除されました。

可能？もしそうなら..ええと...どうすればこれを修正できますか? これは競合状態の典型的なケースですか? どうにかしてこれを防ぐことはできますか？

---

アップデート

• 画像へのリンクを修正しました。
• 生の XML デッドロック ファイルへのリンク。ここに同じリンクがあります。
• データベース テーブル スキーマが追加されました。
• 両方の表の詳細を追加しました。

トランザクションにある次のコードがあります。自分の仕事の単位をどこで/いつコミットすべきかわかりません。

わざと、私が使用しているRespoistoryのタイプについては触れていません。Linq-To-Sql、Entity Framework 4、NHibernateなど。

誰かがどこを知っているなら、彼らはなぜ彼らが言ったのか、どこで説明できますか？（コードを機能させるだけではなく、例を通してパターンを理解しようとしています）。

これが私が持っているものです：-