問題タブ [specification-pattern]

私は次の方法でリポジトリを持っています：

複数の式を渡す必要があります。私は署名を次のように変更することを考えていました：

1. これは可能ですか？
2. このメソッドに渡す式の配列などを作成するにはどうすればよいですか？

現在、次のようにサービスレイヤーからメソッドを呼び出しています。

p => p.Variantsしかし、私は合格したいと思いp => p.Reviewsます、例えば。次に、リポジトリで式を繰り返し処理して、クエリに追加します。

私がこれを行っている理由の背景については、NHibernateを使用したEagerのロードに関するBenFosterのブログ投稿を参照してください。

現在、私の Web サイトには、仕様パターンを含むリポジトリ パターンがあります。ほんの数行のコードで、.aspx ページ内からデータを取得できます。次に例を示します。

私の質問は、私の Web サイトにビジネス層が必要ですか? 答えが「はい」の場合、その理由は? 現時点では、仕様パターンのために、ページとリポジトリの間にあるビジネス層は必要ないようです。

ご意見ありがとうございます。

これは相続の質問だと思いますが、それを使ったパターンを実装することでよりよく把握しようとしているので、よりよく把握するための質問をしたいと思いました。

仕様パターンを使用し、すべてが仕様から派生した多数の仕様を持ち、それらをラッパー仕様クラスでラップする場合：

例 ：

私の質問は、顧客エンティティをacceptCustCreditStatusSpecのIsSatisfiedByメソッドに渡すので（最初の仮定）、顧客エンティティは、unlimitedCreditLimitSpecとSufficientCustCreditAmtSpecの両方の仕様のIsSatisifedByメソッドにどのように渡されるのですか？

ありがとう、

この背後にあるデザインを正しく取得するのに問題があります。データレイヤーを管理するためにリポジトリ パターンを使用しています。私のコントローラー (MVC3) の 1 つで、結合を実行する必要がある LINQ クエリを作成しています。これについて 2 つの質問があります。

1. すべての結合、プロジェクションなどを実行するメソッドをリポジトリに追加する方が良いですか? 私のリポジトリでコントラクト定義が増え続けることになるので、私はそれについて少し躊躇していますか?
2. Post リポジトリに、すべてのアイテムを返す List() メソッドがあるとします。現在、ストア式に変換できないため、linq (結合) クエリでこのメソッドを使用することはできません。以下のコードは repo と呼ばれるクラスを使用していることに注意してください。このクラスは、同じコンテキスト インスタンスを使用してすべてのリポジトリ (投稿、友達) への参照を保持します。

大きな編集: 物事はもう少し明確になりましたが、誰かがここに飛び込んで、すべてを整理するのを手伝ってくれることを願っています;-)。私がやろうとしているのは、リポジトリ パターンと共に仕様パターンを実装することです。問題は、私は POCO を使用しており、私のリポジトリは IObjectSets を使用する IContext インターフェイスを使用していることです。したがって、以下の list メソッドでは、Posts は IObjectSet であり、Context は IContext インターフェースであり、実際のコンテキストを挿入します。

私は読んでいて、 implementing-repository-pattern-with-ef4-poco-supportやimplementing-repository-pattern-with-entity-frameworkなど、すぐに使用できる非常に優れたコードがいくつかあります。

これらの例はどちらも、リポジトリで objectContext を使用しています。それも抽象化したほうがいいのではないですか？

私のリポジトリ:

そして、私のコントローラーメソッドでは:

ただし、以下は機能します（なぜですか？）：

基本的には、ここで説明されている問題と同じです: linq-to-entities-does-not-recognize-the-method

これを回避するにはどうすればよいですか？モデルで定義された関数について調べてきましたが、それが正しい方法かどうかわかりません。

前もって感謝します

場合によっては、いくつかのビジネス ルールを定義する必要があり、仕様パターンが便利なツールになります。例えば：

しかし、パフォーマンスを改善したり、ページ化されたレコードのリストなどに対応したりするために、これらのルールを SQL に「プッシュ」する必要があることがよくあります。

その後、ルールのコードを 2 回 (CLR コードで 1 回、SQL (または ORM 言語) で 1 回) 記述する必要があります。

このようなコードをどのように整理しますか?

コードを同じクラスにまとめておくのが最善のようです。そうすれば、開発者がビジネス ルールを更新する場合に、両方のコード セットを更新するのを忘れる可能性が少なくなります。例えば：

しかし、私たちは今懸念を混ぜ合わせているので、これは私にはかなり醜いようです。

もう 1 つの方法は、LINQ コードをコレクションに対して実行するか、SQL に変換できるため、Linq-To-YourORM ソリューションを使用することです。しかし、最も些細なシナリオ以外では、そのような解決策はめったに不可能であることがわかりました。

職業はなんですか？

linqクエリを実行しようとすると、次のエラーが発生します。

LINQ to Entitiesは、メソッド'Boolean IsCharityMatching（System.String、System.String）'メソッドを認識せず、このメソッドをストア式に変換できません。

人々が同じエラーを受け取る以前の質問をたくさん読みました。これを正しく理解しているのは、LINQ to Entitiesではlinqクエリ式全体をサーバークエリに変換する必要があるため、外部メソッドを呼び出すことができないためです。初期化。私は自分のシナリオをまだうまくいくものに変換することができず、私の脳は溶け始めているので、誰かが私を正しい方向に向けてくれることを望んでいました。私たちはEntityFrameworkと仕様パターンを使用しています（そして私は両方に不慣れです）。

仕様を使用するコードは次のとおりです。

linq式は次のとおりです。

IsCharityMatchingメソッドは次のとおりです。

さらに情報が必要な場合はお知らせください。

どうもありがとう、

アネリー

Expression<Func<User, bool>>次のようなタイプのオブジェクトとして仕様を定義しました。

これは、拡張メソッド構文で記述されたクエリで驚くほど機能します。

しかし、Linq クエリ構文ではそうではありません:

コンパイラは私に与えますcannot implicitly convert type 'Expression<Func<User, bool>>' to 'bool'。

何を与える？私は、Linq クエリ構文は、拡張メソッド構文をドレスアップしたかわいい DSL だと思っていました。私の素敵な仕様をLinqクエリ構文でどのように使用できるか誰か教えてもらえますか?

私はこの種の形式で仕様を使用しています:

これで、この仕様を次の形式で使用できます。

しかし、次のような関連付けられたオブジェクトに対して仕様を使用する方法がわかりません。

これを行う方法はありますか、または仕様の実装を再考する必要がありますか?

それで、私はここで仕様パターンに関するいくつかの投稿を見ましたが、これに対する答えはまだ見つかりませんでした。

私の質問は、n層アーキテクチャでは、仕様を正確にどこで「更新」する必要があるのか​​ということです。

1. それらをサービス層（別名、アプリケーション層と呼ばれることもあります...基本的には.aspxコードビハインドが通信するもの）に配置することはできますが、そうすることで、ビジネスルールを漏らしてしまうような気がします。ドメイン。ドメインオブジェクトが（サービスレイヤー以外の）他の方法でアクセスされる場合、ドメインオブジェクトは独自のビジネスルールを適用できません。

2. コンストラクターインジェクションを介して、仕様をModelクラスにインジェクトでき​​ます。しかし、繰り返しますが、これは「間違っている」と感じます。モデルクラスに注入する必要があるのは、キャッシング、ロギング、ダーティフラグトラッキングなどの「サービス」だけだと思います。それを回避できる場合は、モデルのコンストラクターを散らかす代わりにアスペクトを使用します。大量のサービスインターフェイスを備えたクラス。

3. メソッドインジェクション（「ダブルディスパッチ」と呼ばれることもあります???）を介して仕様を注入し、そのメソッドに注入された仕様を明示的にカプセル化して、ビジネスルールを適用することができます。

4. 「ドメインサービス」クラスを作成します。このクラスは、コンストラクターインジェクションを介して仕様を取得し、サービスレイヤーがドメインサービスを使用してドメインオブジェクトを調整できるようにします。仕様によって適用されるルールはまだ「ドメイン」にあり、ドメインサービスクラスは、調整しているドメインオブジェクトと非常によく似た名前を付けることができるため、これは私には問題ないようです。ここで重要なのは、仕様パターンを「適切に」実装するためだけに、たくさんのクラスとコードを書いているような気がすることです。

これに加えて、問題の仕様は、それが「満たされている」かどうかを判断するためにリポジトリを必要とします。

これにより、特にパフォーマンスの問題が発生する可能性があります。コンストラクタインジェクションを使用する場合、b / cを消費するコードは、おそらく仕様をラップするプロパティを呼び出す可能性があり、それがデータベースを呼び出します。

それで、何かアイデア/考え/記事へのリンクはありますか？

仕様を更新して使用するのに最適な場所はどこですか？