問題タブ [specification-pattern]

ここに概説されているように、Linqを使用して仕様パターンを実装しましたhttps://www.packtpub.com/article/nhibernate-3-using-linq-specifications-data-access-layer

私は今、熱心な負荷をかける機能を追加したいと思っていますが、それを実行するための最良の方法がわかりません。

リンクされた例の汎用リポジトリクラス：

そして仕様の実装：

これはうまく機能しています。今度は、熱心にロードできる機能を追加したいと思います。NHibernateの積極的な読み込みは、クエリでFetchを使用して実行できることを理解しています。

私が探しているのは、熱心な読み込みロジックを仕様内にカプセル化するか、それをリポジトリに渡すか、そしてこれを実現するために必要なLinq /式ツリー構文（つまり、それがどのように行われるかの例）です。

「仕様パターン」を使用して、ソリューション内のドメインオブジェクトを検証することを計画しています。

ソリューションに「仕様」クラスを配置するための「正しい」場所はどこにありますか？「仕様」クラスを含む専用プロジェクトを作成する必要がありますか、それともドメインまたはビジネスプロジェクトレイヤーにそれらをチャックする必要がありますか？

次の例を考えると、仕様パターンが無意味であるかどうか疑問に思っています。

顧客のアカウントに十分な残高があるかどうかを確認したい場合は、次のような仕様を作成します。

ただし、私が疑問に思っているのは、次のようにCustomerクラスのProperty getterを使用することで、仕様パターンと同じ「利点」（ビジネスルールを適切に変更するだけでよいなど）を実現できることです。

クライアントコードから：

だから私の質問は本当にです。プロパティゲッターを使用してビジネスロジックをラップすることと、仕様クラスを作成することの違いは何ですか？

よろしくお願いします！

グリッドを多用する ASP.NET MVC2 アプリがあります。典型的な仕様パターンに効率的なページングとフィルタリングを追加する方法があるかどうかを確認したいと思います。

基本的に、すべてを開始する呼び出しは次のようになります。

これで、以下のようなことを実行して、グリッドのページングとフィルタリングの設定の関数として行のサブセットを取得できることがわかりました。

ただし、すべてのフィルタリングは中間層で行われ、userId によってすべてのレコードが完全にプルされるため、時間の経過とともにユーザーごとに数百のレコードに成長する可能性があります。これは、多くの非効率的なネットワーク チャットを意味します。したがって、明らかに、NHibernate と Linq によって生成された SQL がより適切にフィルター処理されるように、基準を押し下げる必要があります。

LinqRepository コードは基本的に次のとおりです。

例として、PatientByUserIdSpecification には MatchingCriteria があります。

私は以下でそれができると思っていましたが、クエリはまだ広すぎます。

より良い SQL を生成する機能をセットアップするにはどうすればよいですか?

FowlerとEvansによる仕様書に従って、複合仕様パターンを実装しようとしています。

isGeneralizationOf第一印象では、論理積と論理和では実装が異なると思いました。

特に、接続詞の論理は

（1）specXをspecAとspecBの接続詞とします。次に、specAとspecBの両方がspecCの一般化である場合にのみ、specXはspecCの一般化です。

そして、論理和の論理は次のようになると思いました

（2）specYをspecAとspecBの論理和とします。次に、specAまたはspecBのいずれかがspecCの一般化である場合、specYはspecCの一般化です。

ただし、ドキュメントの16ページに、次の方法が示されています。

（1）と（2）の私の推論は正しいですか？それが間違っているのなら、それはなぜですか？それが正しければ、なぜ作者は接続詞と論理和の両方の仕様によって継承される単一のメソッドを定義したのですか？ここでの彼らの意図は何ですか？

私は、マーチン・ファウラーのエンタープライズ・アーキテクチャーのパターンのリポジトリー・パターンのセクションで簡単に説明されている仕様パターンと、Web 上のいくつかの例を調べてきました。ただし、ほとんどすべての例/説明は、ORM と仕様オブジェクトによって実行される IsSatisfiedBy などのメソッドを利用して作成されます (おそらく ORM によって SQL に変換されます)。

SQL で動作するようにどのように適応させるかはわかりますが、一般的に SQL の例が不足しているため、人々がこのパターンを SQL データ アクセス レイヤーとリポジトリ パターンで使用しているかどうか、またその経験/アプローチについて疑問に思っていました。ある場合、またはそのタスクにより適している可能性のある代替案がある場合。

ユーザーがアイテムをサブスクライブし、新しいアイテムの定期的な通知を受け取ることができるシステムを構築しています。ユーザーは、特定のプロパティでフィルタリングして、必要なアイテムを定義する必要があります。

仕様パターンを使用してアイテムをフィルタリングしています。私の考えでは、ユーザーは Web GUI で独自の仕様を定義する必要があります。

フィルタリングは単純です：

問題は、ユーザーごとに異なる仕様を維持するための最良の方法は何ですか? 永続化する方法についての要件はありません。リレーショナル データベース、ドキュメント データベース、xml など、機能するものは何でも。

私は考えることができます：

• 外部 DSL を記述します (そして、rdb の単純な列に格納します)

• 仕様内の各プロパティの行を (rdb に) 格納します。これは、何をフィルター処理するか、および修飾子 (等しい、より大きい) を示します。これにより、かなり多くの行が生成されます。

• 仕様ごとに新しい表を作成 (これが現実的かどうかは不明)

DSL オプションが最もクリーンなソリューションのようです (DSLDSLSpecificationを受け取り、それを Itemservice に渡す a を作成するだけで済みます。複雑にしすぎているのかもしれません。

仕様パターンを把握しようとしていて、少し混乱しています。特定の要件に役立つとは思えませんでした。複雑な仕様の拡張メソッドを好む場合、何が問題なのか知りたいですか? 例えば

仕様化パターンを使用する代わりに、拡張メソッドで長い仕様をラップすると役立つことがわかりました。これの何が問題なのですか?

データの取得に使用される仕様パターンのみを見てきましたが、検証には使用していません。同僚は、変更を保存するときにオブジェクトが無効にならないように、仕様パターンを使用してオブジェクトを「検証」できると提案しました。

例として、Address の値を持つルートの Customer オブジェクトがあるとします。オブジェクトへの変更を追跡し、作業単位に送信できる仕様を作成して、変更を保存する前に住所が有効であること (物理的な住所、都市、州があること) を確認できます。

これについて何か考えはありますか？

主に Josh Smith のmsdn articleに基づいたマスター/詳細クラスがいくつかあります。特に例としては素晴らしいコードですが、リポジトリのサブセットが必要な状況をどのように処理するのが最善か疑問に思っています。

Josh には AllCustomersViewModel というクラスがあり、次のようなコードを作成しています。

PreferredCustomers、ExCustomers、LocalCustomers などが必要な状況をどのように解決しますか??

彼のコードは、それぞれに ViewModel クラスを提案し、そのクラスにリポジトリのフィルタリングがハードコードされています。

または、オプションのフィルターをリポジトリと共に ViewModel に渡す方法はありますか?

あなたのコードはこの特定の問題をどのように解決しますか?

余談ですが、このような問題を解決するために SpeciaficationPattern または IQueryable を使用する方法を示すリンクや良い例はありますか?

乾杯、
ベリル