LINQ クエリ内で自分の仕様を使用しようとしてつまずきました。ここでの問題は、params を使用した私の仕様にあります。

簡単なシナリオを作りましょう:

私が実際にやろうとしていること

少し紛らわしいことはわかっていますが、実際の（大きな）シナリオ内で多くのラウンドトリップを回避しようとしており、エンティティフレームワークで生のLINQを使用することは実際には不可能であることを知っています. 私は非常に多くのブログと失敗した (私の) アプローチを試すのにうんざりしています。誰かが本当に良いアプローチを知っています。それを行う別の方法はありますか？

エラー

System.NotSupportedException: LINQ to Entities はメソッド 'Boolean IsSatisfiedBy(App.Model.Piece)' メソッドを認識せず、このメソッドはストア式に変換できません。

アップデート

基本仕様パターン

アップデート

私がこれを行うと、それはかなり簡単です

リポジトリ

OK、めちゃくちゃ複雑な保険加入データの適格性とレートを計算する必要があります。ポリシーは、年齢、雇用特性、靴のサイズなどに基づいて利用できます。1962年より前に生まれた人は、テキサスに住んでいてプードルを持っている場合を除き、除外される場合があります。

したがって、仕様パターンを実装するクラスを構築できます。入れ子にして仕様、仕様などができます。それは素晴らしいことです。しかし、これをデータベースにシリアル化するにはどうすればよいでしょうか。

c＃クラスをxmlにダンプし、そのままにしておくことができます。しかし、それは脆弱ですが、照会することはほとんど不可能です。クラスをxmlにシリアル化し、それを大きなテキストフィールドにダンプすることには、明確なコードの臭いがあります。

ネストされた仕様をデータベースに入れる方法に対する標準的な答えはありますか？私のGoogle-fuは私に失敗します。

クエリに基づいて X 個のレコードを取得するストアド プロシージャを作成します。この SP は、検索中にレコードをロックする必要がある場合があります。悲観的ロックを使用できないことがわかっているEFも使用しています。

クエリ自体にフィルタリング ロジックを含める代わりに、仕様パターンを使用して、ビジネス ロジックがクエリを指示することを考えていました。このパターンを使用して仕様をリポジトリに渡し、リポジトリが SP を呼び出す場合、SP は仕様をどう処理するかをどのように知るのでしょうか?

仕様は、複数のテーブルにまたがる基準と異なる列での並べ替えで構成できます。

このシナリオで仕様パターンを使用することは理にかなっていますか?それとも、そこで定義されたクエリとフィルタリングを使用して SP を作成する必要がありますか?

以下は、EntityFrameworkで使用するように設計された汎用リポジトリの実装です。この演習では、その「良さ」または「悪さ」を無視します。

NHibernateでのこのコードはどのようになりますか？

乾杯、
ベリール

ノート

これは、リポジトリを設計する方法や、リポジトリを使用するかどうかについての質問ではありません。EFからNHibへの単純な翻訳...

Composite Specification Pattern の LINQ ベースの実装は多数あります。Subsumption を使用したものは見たことがありません。

文書化されている (ブログなど) か、オープン ソースとして公開されている例はありますか? ExpressionVisitor ですべての仕様を正規の論理形式 (CNF/DNF) に変換することで、これがどのように機能するかについてのアイデアと概念実証がありますが、これが過度に複雑であることが懸念されます。より良い方法はありますか？

私はかなり長い間、典型的なリポジトリパターン（特殊なクエリのメソッドのリストなど）によって提示される問題の適切な解決策を探してきました。http：//ayende.com/blog/3955/repository-を参照してください。 is-the-new-singleton）。

特に仕様パターンを使用して、コマンドクエリを使用するというアイデアが本当に気に入っています。ただし、仕様に関する私の問題は、単純な選択の基準（基本的にはwhere句）にのみ関連し、結合、グループ化、サブセット選択、射影など、クエリの他の問題を処理しないことです。基本的に、正しいデータセットを取得するために多くのクエリが実行する必要のあるすべての余分なフープ。

（注：コマンドパターンのように「コマンド」という用語を使用します。これはクエリオブジェクトとも呼ばれます。クエリとコマンド（更新、削除、入れる））

だから私はクエリ全体をカプセル化する代替案を探していますが、それでも十分な柔軟性があるので、コマンドクラスの爆発的な増加のためにスパゲッティリポジトリを交換するだけではありません。

私はたとえばLinqspecsを使用しましたが、選択基準に意味のある名前を割り当てることができることにはある程度の価値がありますが、それだけでは十分ではありません。おそらく私は、複数のアプローチを組み合わせた混合ソリューションを探しています。

私は、この問題に対処するため、または別の問題に対処するために他の人が開発した可能性があるが、それでもこれらの要件を満たす解決策を探しています。リンクされた記事で、AyendeはnHibernateコンテキストを直接使用することを提案していますが、クエリ情報も含まれている必要があるため、ビジネスレイヤーが大幅に複雑になると思います。

待機期間が経過するとすぐに、これに報奨金を提供します。ですから、あなたの解決策を価値のあるものにして、良い説明をしてください。私は最良の解決策を選び、次点者に賛成します。

注：ORMベースのものを探しています。明示的にEFまたはnHibernateである必要はありませんが、これらが最も一般的であり、最適です。他のORMに簡単に適応できるのであれば、それはボーナスになります。Linq互換もいいでしょう。

更新：ここに良い提案があまりないことに本当に驚いています。人々は完全にCQRSであるか、完全にリポジトリキャンプにいるようです。私のアプリのほとんどは、CQRSを保証するほど複雑ではありません（ほとんどのCQRS支持者は、CQRSを使用すべきではないとすぐに言います）。

更新：ここには少し混乱があるようです。私は新しいデータアクセステクノロジーを探しているのではなく、ビジネスとデータの間の適切に設計されたインターフェイスを探しています。

理想的には、私が探しているのは、クエリオブジェクト、仕様パターン、およびリポジトリの間のある種のクロスです。上で述べたように、仕様パターンはwhere句の側面のみを扱い、結合、副選択などのクエリの他の側面は扱いません。リポジトリはクエリ全体を扱いますが、しばらくすると手に負えなくなります。 。クエリオブジェクトもクエリ全体を処理しますが、リポジトリをクエリオブジェクトの爆発的なものに単純に置き換えたくはありません。

ドメイン駆動設計を使用してアプリケーションを開発しています。私が使用しているパターンの1つは、リポジトリパターンです。簡単にするために、次のクラスとインターフェイスがあるとしましょう。

Car-車のドメインの概念を表すドメインクラス。

ICarRepository-Carオブジェクトへの変更を追加、削除、または保存するためのインターフェース。

私の問題は、データベース内のすべてのCarオブジェクト間でSomeUniqueCodeプロパティの一意性を確認する方法です。そのプロパティは、オブジェクトのライフサイクル中いつでもユーザーによって変更されます（自動生成されません）。もちろん、1つの解決策はデータベースに一意のキーを配置することですが、それはDDDの原則ではありません。単一のオブジェクトを検証するために使用される仕様パターンを見てきました。そのパターンは、Carオブジェクトのセットにどのように適用されますか？

Specificationクラス（CheckUniqueCarSpecificationと呼びましょう）がICarRepositoryにアクセスすることは正当ですか？

設計パターンは特定のコードではなく、設計によって設定されることを知っていますが、パターンを曲げすぎて設計に従わなくなったのではないかと心配することがあります。

たとえば、仕様パターンは次のようになります。

しかし、私にはこれはあまり読みにくいです:

そこで、コンストラクター内で候補を渡すように変更しました。

さらに、bool 演算子をオーバーロードしたので、次のように記述できます。

ここで、設計パターンの経験が豊富な人から、これをひねりすぎていないかどうか、またどのようなリスクに注意する必要があるかを知りたいと思います。

ブログ Web サイトを作成しているとしましょう。複数の著者による最近のブログ投稿を「優先度」でソートして表示します。優先度が一番上。優先度は、以下を含む公式によって決定されます。

1. 投稿が公開されたのはいつですか
2. どれだけのコメントを集めたか

注文は常にリアルタイムで正確でなければなりません。

優先順位によるソートは簡単です。問題は、私たちのウェブサイトが非常に人気があり、1 分あたり数百の割合でコメントが飛び交っているとしましょう。彼らは何十もの投稿に飛び込みます。

このシナリオを処理するパターンはありますか? 言い換えれば、投稿にコメントがあるたびに優先度フィールドを更新し、ページが読み込まれるたびに投稿を並べ替えるよりも良いことはありますか? 大量のユーザー アクティビティによって順序が頻繁に変更されるため、ポスト オーダーのキャッシュはあまり役に立ちません。

「パターン」については、コードとデータベース スキーマの両方の観点から話しています。

以下の数百行のコードで特定のビジネスルールを実装する必要があります

これを効果的に実装したり、すべての異なるルールに適用できるようにコードを再利用したりできる設計パターンはありますか? 以下のようなものを作成する仕様パターンを聞いた

そして、Is、And、Or メソッドの実装ですが、これでは if else を書く必要がないと思います (私の理解が間違っている可能性があります)...

if else ステートメントが非常に多いこのようなビジネス ルールを実装するための最善の方法はありますか?

EDIT : サンプルの例です。A、B、C などはクラスのプロパティです。これら以外にも、同様のルールがたくさんあります。このための一般的なコードを作成したいと思います。