適切に設計されたクエリコマンドや仕様
私はかなりの時間をかけて、典型的なリポジトリパターン（特殊なクエリのメソッドのリストの増加など）によって提示される問題の適切な解決策を探していました。http：//ayende.com/blog/3955/repository-を参照してください。 is-the-new-singleton）。 特に仕様パターンを使用することで、コマンドクエリを使用するアイデアが本当に気に入っています。ただし、仕様に関する私の問題は、単純な選択（基本的にはwhere句）の基準にのみ関連し、結合、グループ化、サブセットの選択または射影などのクエリの他の問題を処理しないことです。基本的に、多くのクエリが正しいデータセットを取得するために通過しなければならないすべての追加のフープ。 （注：クエリオブジェクトとも呼ばれるコマンドパターンのように、「コマンド」という用語を使用します。クエリとコマンド（更新、削除、インサート）） したがって、クエリ全体をカプセル化する代替手段を探していますが、それでも、スパゲッティリポジトリをコマンドクラスの急増に交換するだけではないほど十分に柔軟性があります。 私は、たとえばLinqspecsを使用しましたが、選択基準に意味のある名前を割り当てることができることに価値があると感じましたが、それだけでは不十分です。おそらく、私は複数のアプローチを組み合わせた混合ソリューションを探しています。 この問題に対処するため、または別の問題に対処するために他の人が開発した可能性のある解決策を探していますが、これらの要件は満たしています。リンクされた記事では、AyendeがnHibernateコンテキストを直接使用することを提案していますが、クエリ情報も含める必要があるため、ビジネスレイヤーが大幅に複雑になっているように感じます。 待機期間が過ぎ次第、私はこれについて報奨金を提供します。だから、良い説明を付けてあなたの解決策を報奨に値するものにしてください、そして私は最良の解決策を選び、そしてランナーを賛成します。 注：私はORMベースの何かを探しています。EFやnHibernateを明示的に指定する必要はありませんが、これらは最も一般的であり、最も適しています。それが他のORMに簡単に適用できる場合は、ボーナスになります。Linq互換性もいいです。 更新：ここに良い提案があまりないことに本当に驚いています。人々は完全にCQRSであるか、完全にリポジトリキャンプにいるようです。私のアプリのほとんどは、CQRSを保証するほど複雑ではありません（ほとんどのCQRS擁護者が使用するべきではないとすぐに言っています）。 更新：ここで少し混乱があるようです。私は新しいデータアクセステクノロジーを探しているのではなく、ビジネスとデータ間の適切に設計されたインターフェイスを探しています。 理想的には、私が探しているのは、クエリオブジェクト、仕様パターン、およびリポジトリの間のある種のクロスです。上で述べたように、仕様パターンはwhere句の側面のみを扱い、結合や副選択などのクエリの他の側面は扱いません。リポジトリはクエリ全体を扱いますが、しばらくすると手に負えなくなります。クエリオブジェクトもクエリ全体を処理しますが、単純にリポジトリをクエリオブジェクトの爆発に置き換えたくありません。