私はリポジトリと作業単位をプロジェクトに統合するための「正しい」方法を探していましたが、さまざまなバリエーションにまたがって実行し続けています。uowオブジェクトのメンバーとしてリポジトリを持っているものもあります。他には、IUnitOfWorkインターフェースを実装するリポジトリがあります。uowオブジェクトがコンストラクターへの引数としてリポジトリーに渡されるところを見てきました。
他の方法よりも一方向にそれを行うことに何か利点はありますか?コンセンサスがある場合、それは何ですか?
私はリポジトリと作業単位をプロジェクトに統合するための「正しい」方法を探していましたが、さまざまなバリエーションにまたがって実行し続けています。uowオブジェクトのメンバーとしてリポジトリを持っているものもあります。他には、IUnitOfWorkインターフェースを実装するリポジトリがあります。uowオブジェクトがコンストラクターへの引数としてリポジトリーに渡されるところを見てきました。
他の方法よりも一方向にそれを行うことに何か利点はありますか?コンセンサスがある場合、それは何ですか?
そこにコンセンサスがあるとは言えませんが、このトピックについて多くの建築家と話をしたことに加えて、私はかなりの時間を費やしてこの問題を評価してきました. 私が思いついたのは、オブジェクト管理 (リポジトリ) とトランザクション (UnitOfWork) を疎結合し、互いに独立させたいということです。リポジトリは、トランザクションを使用せずに実行できる必要があり、その逆も同様です。リポジトリとの関係に関して言えば、Unit of Work は実際には単なるトランザクションのラッパーです。あなたの場合、おそらく TransactionScope 実装を使用して EF2 リポジトリ操作をラップします。このフレームワークでは、トランザクション管理を DataServices 名前空間/プロジェクトに配置し、ベース リポジトリ クラスを ObjectAccess 名前空間/プロジェクトに配置しました。そこから、リポジトリ操作と作業単位操作の両方の EF2 実装を作成しました。ソースを示すことはできませんが、基本的に私が行ったことは次のとおりです。
このフレームワークの最初の安定版をリリースしようとしています。幸運を!
次のページを考えると、MS コンセンサスはリポジトリを公開する UnitOfWork であると言えます。
http://msdn.microsoft.com/en-us/library/ff714955.aspx
どちらも、1 人の単純化されたブログ投稿の例ではなく、MS のガイダンスのようです。
それを行う「正しい」方法はありません。状況に適した実装を見つけて使用してください。私は個人的に物事をシンプルに保つのが好きなので、通常はすべてのプロジェクトで汎用リポジトリを使用します (UoW インターフェース/パターンはまったくありません)。