問題タブ [unit-of-work]

私は現在、NHibernateを使用する既存のASP.NETMVCアプリケーションに作業単位パターンを追加する方法を研究しています。さまざまな実装にさまざまなバリエーションがあり、特定の状況でどのメソッドが最適に機能するかを判断するのに苦労しています。

助けるために、私はStack Overflowコミュニティに、ASP.NETMVCアプリケーションにUnitofWorkパターンを実装するためのお気に入りの方法をリストするように依頼したいと思いました。

おそらく、コントローラーを作成するときにIoCを使用してNHibernateセッションをインスタンス化し、それをリポジトリーに渡します。または、作業単位のクラス/インターフェイスを作成することもできます。アプローチを説明した後は、遠慮なく追加のリソースにリンクしてください。

また、メソッドに関連する長所と短所が存在する場合は、それらを必ずリストしてください。

ウィンザーを始めたとき、DIは簡単だと思いました。今、それは私にますます混乱を引き起こしています。

リポジトリは、シングルトンライフサイクルを持つクラスとして私を襲います。アプリケーションの存続期間中にFoosをデータベースにロードして保存するには、FooRepositoryの単一インスタンスが必要です。

ただし、各リポジトリは、ダーティチェックを実行し、データベースなどを操作するUnitOfWorkへの参照を保持します。UnitOfWorkのライフサイクルはPerWebRequestです。シングルトンインスタンスのように、UnitOfWorkがシングルトンであることはまったく意味がありません。 （たとえば）複数のユーザーセッションによって同時に行われた変更をフラッシュします。

したがって、UnitOfWorkへの参照を保持するシングルトンFooRepositoryがあり、セッションの最後に破棄されます。リポジトリの動作にどのような影響があるかはわかりませんが、よく聞こえません。

WebアプリでRepositoryクラスとUnitOfWorkクラスのライフサイクルを管理する適切な方法を、簡単な英語で（おそらくコードを使用して）誰かが説明できますか？

私の特定のアプリケーションは、Entity Framework を使用した ASP.NET MVC アプリです。

Entity1 への参照 (* から 1) を含むオブジェクト Entity0 があります...

Entity_0 にもいくつかのロジックがありますが、このロジックでは Entity_1 が null でないことが必要です...

コントローラーでモデル バインディングを介して Entity_0 の新しいインスタンスが作成されると、Entity_1_ID プロパティが設定されますが、Entity_1 ナビゲーション プロパティは、データベースに永続化されるまで null のままです。

GetEntity_2() を呼び出して、Entity_0 と Entity_2 を 1 つの作業単位としてデータベースに保存する必要があります。これは、関数を呼び出す前に、リポジトリから Entity_1 を手動で取得して Entity_0 に割り当てる必要があることを意味します。

私が検討したもう 1 つのオプションは、Entity_1 を GetEntity_2 メソッドのパラメーターにすることですが、それ以外の場合、そのメソッドが Entity_1 と呼ばれる場合は null にならないため、パラメーターを要求するのは冗長です。

したがって、明らかにすべてが現在機能していますが、私の質問は、a) null 参照例外をスローする可能性のあるメソッドを持っているか、b) 一部のみを使用する必要があるメソッドパラメーターを指定することにより、OOP 設計規則に違反しているかどうかです。時間。

ナビゲーション プロパティを手動で割り当てなければならないのは、本当に困ります。どうすればこれを改善できるかについて、いくつかの提案があることを願っています。

ありがとう！

作業単位インスタンスをリポジトリに渡すことで、作業単位パターンを実装しようとしています。

Global.asaxからの関連コード。

リポジトリコンストラクタ：

私が欲しいのは、SqlUnitOfWorkリクエストごとに最大1つのインスタンスが作成され、（それぞれのコンストラクターを介して）リポジトリに渡されることです。

バインディングのInRequestScope()方法はIUnitOfWork十分ですか？そうでない場合、どうすればこれを達成できますか？

ef4を使用して作業単位を作成する方法の例をいくつか見つけました。私は、di / iocを使用していません。物事をシンプルに保ちたいと思います。これは、例（90％に触発されたもの）です。これから使うパターン最後にもう一度意見を伺いたいと思います。

そして最後に

IUnitOfWorkとIDisposalを削除した後、CreateUserは次のようになります。

次のアーキテクチャに基づく MVC Web アプリがあります。

作業単位パターンを使用する Asp.Net MVC2、Ninject、Fluent NHibernate、MySQL。

MySQL へのすべての接続は、SHOW PROCESSLIST クエリ結果のエントリとして表示できるスリープ接続を生成します。

最終的には、アプリ プールの制限を超えて Web アプリをクラッシュさせるのに十分な数の接続が生成されます。

接続が正しく破棄されていないと思われます。

これが事実である場合、これはどこでどのように発生する必要がありますか?

ここに私が使用しているコードのスナップショットがあります:

「スタブテクニック」を使用してPOCOを更新しています（分離されたコンテキスト、ASP.NET MVCで使用されます）。

これは私が現在私のコントローラーに持っているコードです（これは機能します）：

ご覧のとおり、いたるところにコードの臭いがあります。:)

いくつかのポイント：

1. 基本的にすべてに依存性注入（インターフェースベース）を使用します
2. Unit of Workパターンを使用して、ObjectContextを抽象化し、複数のリポジトリ間で永続性を提供します
3. 現在、私のIUnitOfWorkインターフェイスには1つのメソッドしかありません。void Commit();
4. コントローラーはDIによって注入しIUserContentServiceますIUnitOfWork
5. IUserContentServiceFindを使用するリポジトリでの呼び出しObjectContext。

これらは、上記のコードでは気に入らない2つのことです。

1. IUnitOfWorkをとしてキャストしたくありませんMySqlServerObjectContext。
2. コントローラーに気を配らせたくないApplyCurrentValues

基本的に、コードは次のようになります。

どのように私はそれを行うことができますか？（または同様のもの）。

タイプ（ジェネリックスの組み合わせ、複数化）に基づいてエンティティセット名を計算するための賢い方法はすでにあるので、それほど心配する必要はありません。

しかし、私はどこに置くのApplyCurrentValuesが最適なのか疑問に思っていますか？IUnitOfWorkこれは永続性（EF）の問題であるため、インターフェイスに配置することは適切ではないようです。同じ理由で、それはサービスに属していません。これをクラスに入れるとMySqlServerObjectContext（意味があります）、このクラスに直接アクセスできるものはないため、どこから呼び出すのでしょうか。何かが要求すると、DIを介して注入されますIUnitOfWork。

何かご意見は？

編集

以下にスタブ手法を使用した解決策がありますが、問題は、更新しているエンティティを事前に取得した場合、そのキーを持つエンティティがすでに存在することを示す例外をスローすることです。

どうすればこれを解決できるかわかりませんが、どちらが理にかなっていますか？

「エンティティがすでにアタッチされているかどうかを確認し、アタッチされていない場合はアタッチする」必要がありますか？

EF4の専門家は助けてくれますか？

編集

気にしないでください-解決策を見つけました。以下の回答を参照してください。

私は次の実装を持っていますが、セッションとトランザクションに NHibernate を正しく使用しているかどうかについてフィードバックをお願いします。

ニンジェクトバインディング

使用例を次に示します。

以前の実装では、IUnitOfWork をリポジトリ コンストラクターに次のように挿入していました。

しかし、Dispose() メソッドは実行されず、後続の呼び出しで次の例外がスローされます。「破棄されたオブジェクトにアクセスできません。オブジェクト名: 'AdoTransaction'.」

この投稿の長さについてお詫び申し上げますが、回答の可能性を高めるために、できるだけ詳細を提供したいと思いました. 前もって感謝します。

複数のデータベースからのデータを統合する既存のアプリケーションに新しい機能を追加しています。つまり、クライアントやその会計士が自分の場所に関する財務情報にアクセスして更新できるようにします。アプリケーションには、Web クライアント (これをすぐに Silverlight クライアントに置き換えることを考えています)、アプリ サーバーで実行されるサービス層、およびデータベース層の 3 つの層があります。

私が所有権を取得したとき、アプリケーションは 3 層であるにもかかわらず、非常に単純化されていました。すべてに ADO.NET を使用しており、Web サービスはデータベースの 1 つでの動的 (文字列) SQL クエリの単なるパススルーです。私の最初の仕事は、既存のコードを「クリーンアップ」することでした。アプリにはオブジェクト指向はなく、すべてがフラットでした。LINQ-to-SQL を活用するためにアプリケーションのリファクタリングを開始し、リポジトリ パターンを実装してビジネス ロジックをテスト可能にしました (言うまでもなく、データ アクセス テクノロジを ADO.NET から L2S に進化させ、できればさらにEntity Framework) を実装し、実際に .NET の機能を使用するようにコードを作り直しました。

ほとんどの場合、すべてのページが (Web サービスを介して) データベース内のテーブルまたはビューに対する単純なクエリであるため、Web アプリは簡単なものです。アプリ サーバー側では、各データベースの DataContext と各エンティティのリポジトリ (または DDD 用語を使用した集約ルート) になりました。コンストラクター インジェクション (Castle Windsor) を使用して、サービス クラスに適切なリポジトリ インスタンスを設定し、リポジトリで使用される DataContext にも同様に設定します。

4 つのデータベースにまたがるロジックを必要とするアプリケーションに編集機能を追加する必要があり、適切なアプローチが見つからないことを除けば、これで問題ありません。アプリのフローとアーキテクチャが一貫しており、ジュニア グレードの開発者が保守できることが重要です。(私を除けば、チームは基本的に VB6 開発者であり、VS と BCL を使用しているため、.NET をプログラミングしていると考えています。彼らは、パターン、プラクティス、単体テスト、モックなどについてほとんど知りません) </ p>

編集ビューを機能させるために必要なものを見ていきましょう。

1. ページが最初に読み込まれると、「編集可能な」会計期間のリストが生成されます。
   1. このリストは、SQL Server データベース (「メタデータ」データベースと呼びます) に含まれる一連のルールに基づいています。表の各行は、会計期間を編集可能な時間枠とともに名前で識別します。
   2. これらのルールは、期間名と年を実際の日付にマップする DB2 財務データベースのテーブルを照会するために使用されます。このクエリは、終了日が過去で、終了日 (終了日と上記の編集の長さ) が今日より後のすべてのエントリを返します。
2. このページでは、選択した期間がデフォルトで最新のものになります。期間が選択されると、選択した期間中に現在のユーザーが編集できる場所のリストを作成する別のリクエストを発行します。
   1. まず、「Security」データベースからユーザーのセキュリティ情報を調べて、そのユーザーが Accountants ロールに属しているかどうかを判断する必要があります。その場合、メタデータ データベースにクエリを実行して、現在のユーザーのクライアントのリストを取得する必要があります。そうでない場合は、現在のユーザーの clientID を使用します。
   2. 次に、DB2 財務データベースにクエリを実行して場所のリストを取得し、選択した期間とユーザーがアクセスできる clientID のリストに基づいてフィルタリングします。また、ステータスに基づいてフィルタリングするため、その期間中にアクティブだった場所のみを返します。
3. ピリオドと同様に、ページは選択された場所をリストの最初の場所にデフォルト設定します。場所が選択されると、選択した期間中のその場所の実際の財務データをもう一度要求します。
   1. このリクエストは「ステージング」データベースに対して行われ、非常に簡単です。
4. ユーザーが別の期間または場所を選択すると、このすべてが繰り返されます。

それでは、#2 を取り上げて、Unit Of Work パターンと Repository パターンを使用してサービス アプリケーションにこれを実装する方法について説明しましょう。まだEFにジャンプしていないので、そのデータベースを操作するときにADO.NETを使用する必要があります。しかし、彼らはいつでも気が変わる可能性があるため、可能な限りデータアクセス技術にとらわれないソリューションが欲しいので、それであなたを遅らせないでください. 実際、彼らはパラダイムをシフトし、現時点で私が知っている限りで NHibernate に移行することができます。私はサービス ファサードから DataContext に到達することに関心があり、DataContext (または ObjectContext) がどのように実装されているかについてはあまり関心がありません。

現在のユーザーの資格情報と選択した会計期間を使用して Web サービス メソッドを呼び出し、上記の #2 で説明した手順を実行し、適切な場所のリストを返す実装について説明してもらえますか?

ふぅ… 理解するのが大変でした。整理してくれてありがとう。

現在、ビジネス オブジェクトに独自の「作業単位」機能を採用していますが、すべてのデータベースの永続性を管理するために nHibernate に移行することを検討しています。nHibernate は独自の作業単位を管理するため、データに加えられた変更の履歴ログを書き込むことができるように、(フラッシュされたときに)「ダーティ」オブジェクトを調べる方法はありますか?

もちろん、トランザクションの会話が長い場合は、プロパティのデータベース値をデータベースに永続化された新しい値と比較することにのみ関心があり、行われた中間の変更はデータベースに記録する必要はありません。

誰かアドバイスはありますか？