問題タブ [unit-of-work]

プレゼンテーション層で nHibernate の依存関係を切り離す方法についてアドバイスが必要です。現在、次のレイヤーで構成される (簡略化された) 3 層の C# winforms アプリケーションがあります。

• ユーザー インターフェイス (UI)
• ビジネスロジック (BAL)
• データ アクセス ロジック (DAL)

このアプリケーションを ORM (nHibernate) に移行しており、理想的には nHibernate を参照する DAL のみを使用したいと考えています。また、nHibernate に含まれる「Unit of Work」機能を採用し、「Session per conversation」方式を採用したいと考えています。

これを実現するには、UI でセッションを作成して開き、セッションを BAL 経由で DAL に渡す必要がありますが、BAL と DAL の両方で nHibernate への依存関係を作成しないと、これを実現できません。

アドバイスをいただければ幸いです。UI と BAL で nHibernate への参照を避けるには、アーキテクチャをどのように構築する必要がありますか。何か案は？

また、UI に DAL への参照を持たせたくないことも付け加えておく必要があります。

UI => BAL => DAL

DDD パターンでは、作業単位をリポジトリと結合する必要がありますか? 作業単位インターフェースを実装するリポジトリ、作業単位自体の動作を実装するリポジトリ、作業単位を表すプロパティを持つリポジトリなど、いくつかの異なる例を見てきました。 UoW の存続期間中の複数のリポジトリ インスタンス。後者の場合、それは一種のアンチパターンのように思えます... つまり、コンシューマーはリポジトリ インスタンス間で UoW のインスタンスを共有することを本当に知る必要があるのでしょうか? それはカプセル化され、消費者に公開されるべきではありませんか?

これらの異なるアプローチの利点とその理由について、意見を聞きたいと思います。

ありがとう。

Commit()Asp.Net MVCアプリのUnitOfWorkはどこに呼び出す必要がありますか？それでも、コントローラーユニットをテスト可能にしてください。

HttpModuleを使用しますか？ベースコントローラーを作成して使用しOnActionExecutedますか？またはGlobal.asax Application_EndRequest():？

簡単な質問です。

Castle.Windsor、nHibernate、および ASP.NET MVC で UnitOfWork を使用するにはどうすればよいですか?

次に、拡張された詳細について説明します。パターンを理解するための私の探求では、具体的にインストールする必要がある方法に関して、UnitOfWorkと組み合わせて直接的な例を使用するものに出くわすのに苦労しています。Castle.Windsor

ここまでが私の理解です。

IUnitOfWork

• IUnitOfWorkインターフェイスは、パターンを宣言するために使用されます
• UnitOfWorkクラスはCommit、Rollbackトランザクション、および公開する必要がありますSession。

そうは言っても、ここに私のIUnitOfWork. （私は使用していますFluent nHibernate）

これが私のCastle.Windsorコンテナブートストラップ（ASP.NET MVC）です

だから今、私のGlobal.asaxファイルには、次のものがあります...

リポジトリ

ISessionこれで、をリポジトリに渡す必要があることがわかりました。では、と仮定しましょうIMembershipRepository。

だから私は今、混乱しています。この方法を使用するISessionと、 が適切に破棄されず、UnitOfWorkが使用されることはありません。

Web リクエスト レベルに移行する必要があるとの連絡を受けましたがUnitOfWork、実際にこれを行う方法を説明するものは見つかりません。私はいかなる種類の a も使用しませんServiceLocator(私が試したとき、これも悪い習慣だと言われました...)。

混乱 -- はどのようUnitOfWorkに作成されるのですか?

一般的に、私はこれを理解していません。UnitOfWork私の考えでは、コンストラクターに 渡し始めようと考えていRepositoryましたが、それが Web リクエストに含まれる必要がある場合、この 2 つがどこに関係しているのかわかりません。

さらなるコード

これは、質問に対して正しい情報を提供しないという習慣があるように見えるため、明確にするための追加のコードです。

インストーラー

UnitOfWork

これが私のUnitOfWorkクラスの逐語です。

Unit of Work パターンに従ってインターフェイスを作成しています。私のインターフェースは次のようになります。

ここまでは順調ですね。今では、EF4 をデータ プロバイダーとして使用するデータ層に実装しています。「クエリ」メソッドのこのコードを思いつきましたが、あまりきれいではないと思います。それを行うための賢い方法があると思いますが、実際にはわかりません。

ここで見られる問題は、すべての IF が毎回テストされることです。ただし、カスケード if-else でそれらをチェーンすることはできますが、それでもかなりひどいように見えます。その他の問題は、追加される可能性のある新しいエンティティごとに 1 行を手動で追加する必要があることですが、それは私の主な関心事ではありません。

誰でもこれについて何か良いアドバイスはありますか? ありがとう。

私はリポジトリと作業単位をプロジェクトに統合するための「正しい」方法を探していましたが、さまざまなバリエーションにまたがって実行し続けています。uowオブジェクトのメンバーとしてリポジトリを持っているものもあります。他には、IUnitOfWorkインターフェースを実装するリポジトリがあります。uowオブジェクトがコンストラクターへの引数としてリポジトリーに渡されるところを見てきました。

他の方法よりも一方向にそれを行うことに何か利点はありますか？コンセンサスがある場合、それは何ですか？

バックグラウンド

私が理解しているように、Unit of Work (UoW) パターンは基本的にトランザクション セマンティクスを提供します。つまり、リポジトリによって永続化された集約のドメインが与えられた場合、UoW クラスを使用すると、ドメインのコンシューマーはリポジトリ メソッドの呼び出しをアトミック操作に登録できます。私たちが持っているとしましょう：

の実装はIRepositoryリレーショナル データベースを使用し、 の実装はIUnitOfWork.Commit単にデータベースとのトランザクションをセットアップし、登録されたすべての操作に対して適切なインスタンスでSaveorを呼び出します。上で概説したことは、Aggregate Root、Repository、および UoW パターン (NHibernate/EF とそのすべての肥大化した栄光にもかかわらず) の標準的で直接的な解釈であると言えます。RemoveIRepository

これまで、私は集約ルート境界の概念を、ある集約から別の集約への参照を、ソース集約のターゲット集約の Id プロパティによってオブジェクト化する必要があるという意味として解釈してきました。例えば：

質問

上記の関心の分離と集約境界の解釈を考えると、トランザクションで集約を作成し、リポジトリで生成された Id を別の集約に保存する必要がある消費者にトランザクション サポートをどのように提供しますか? たとえば、 と を に設定しUserてBlogトランザクション的に作成するにはどうすればよいですか?Blog.UserIdUser.Id

私はいくつかの回答を思いつきました (コミュニティ wiki とマークされています) が、とにかくここに私の質問を投稿して、フィードバックとより多くの回答を求めています。

私が理解しているように、UnitOfWorkクラスは、ドメイン内のビジネストランザクションの概念を表すことを目的としています。これは、データベーストランザクションを直接表すことは想定されていません。これは、可能な実装の1つだけの詳細です。

Q：では、なぜ作業単位パターンに関する多くのドキュメントが「コミット」および「ロールバック」メソッドに言及しているのですか？

これらの概念は、ドメインまたはドメインの専門家にとって何の意味もありません。ビジネストランザクションは「完了」できるため、UnitOfWorkは「Complete」メソッドを提供する必要があります。同様に、「ロールバック」メソッドの代わりに、「クリア」としてモデル化する必要がありますか？

アップデート：

回答：以下の両方の回答が正しいです。UoWには、オブジェクト登録と発信者登録の2つのバリエーションがあります。オブジェクト登録では、ロールバックはすべてのメモリ内オブジェクトへの変更を元に戻すのに役立ちます。発信者登録では、ロールバックは記録されたすべての変更をクリアするのに役立ち、その後のCommitの呼び出しは何もしません。

EntityFrameworkリポジトリで作業単位パターンを実装しました。**ゴルフクラップ**

同じコミット内で複数のインセットや削除を行うための一般的な方法は何ですか？

例：5つの新しいオブジェクト/エンティティを追加し、何らかの理由でエンティティ＃3を削除したいとします。

これは..のように機能しますか..エンティティを追加し、次に1をデータベースから削除する必要がありますか？それとも、これはEFエンティティリストに対してのみ発生しますか？

これは悪い習慣ですか？すなわち。追加/更新と削除を混在させないでください。常に削除する前にコミットしますか？

UnitOfWorkとリポジトリパターンを使用するプロジェクトを設定しようとしています。

現在、IoCとEF4を使用できないため、少し依存関係のあるLinqとDataContextを試しています:(。これらすべての概念の統合について少し混乱していることを隠していません。I DataContextがオブジェクトに加えられた更新を認識しないが、データベースに新しいエンティティを追加するたびに、コードをデバッグしていることに気づきました。

私は多くのことを読みましたが、私の問題を見つけることができません。おそらくそれは簡単なステップです。先に進む前に、これが私が持っているものです：

たとえば、fooというオブジェクトがあります...コンストラクターでfooRepositoryの新しいインスタンスを作成するfooコントローラーがあります。fooRepositoryで、DataContextをラップするUnitOfWorkへの参照を追加します...そうですか？これが私のコードです

どんな助けや提案も歓迎されます！

すべてのコードを投稿してすみませんが、これに夢中になるのは約1週間です。