問題タブ [specification-pattern]

私の読書から、仕様パターンはデータをフィルタリングするために必要なメソッドの数を大幅に減らすことができるようです。仕様パターンを使用すると、どのようなメリットがありますか？あなたが気づいた予期せぬ利益がありましたか。逆に、どのような落とし穴に遭遇しましたか？

これは主に思考実験です。これはすべてサンプルコードです。私の目標は、仕様パターンを使用して、ファクトリ内の条件付きコードの巨大なブロックを排除することでした。したがって、このサンプルには、適切な IStatusUpdate の実装を取得する StatusData オブジェクトがあります。

次の一連のテストがあります。

これまでの My Factory の実装は次のようになります。

私が落ち込んでいるところは、ステータスオブジェクトによって満たされる仕様を発見した後、その仕様を IStatusUpdate を実装する型にどのようにマップするかということです..私は困惑しています.

IStatusUpdate 実装者への仕様のマッピングが必要であると誰かが正しく提案しました。このマッピングは工場の責任のようで、仕様から外れると SRP 違反の匂いがします。その責任を持つMapperクラスを作成することはできますが、それはあまり一般的ではないようで、マッパーを仕様にどのようにマップするかという疑問も生じます。

ここには、私が見逃している小さな飛躍がまだ 1 つあります。

NHibernate を使用してデータベースにクエリを実行するための仕様パターンをどのように実装しますか? (LINQ to NHibernate なし) 仕様パターンについてはよく読みましたが、そのほとんどは検証とメモリ コレクション オブジェクトのクエリに関するものでした。

私が知る限り、このような仕様インターフェイスで DetachedCriteria を使用する最良の方法。

これを行う代替またはより良い方法はありますか？

LosTechies.com の Chris Missal による仕様パターンに関する一連のブログ (こことここ) を読んだ後、より完全な例を見つけることに本当に興味があります。より肉付けされた例や、このパターンを使用するオープン ソース プロジェクトをどこで見つけることができるか知っている人はいますか?

Linq to SQL と、分離されたリポジトリを備えた DDD スタイルのドメイン レイヤーを使用して、L2S の問題をドメイン レイヤーに流出させずに仕様パターンを実装する方法について、まだ理解できる良いアイデアはありますか? :)

一連のトランザクション データの選択を取り巻く複雑なビジネス ロジックがあり、それらのルール/仕様をドメインが所有することを望んでいます。また、ドメインの永続性を無視し続けることにも成功しています。

仕様を実装するために、ドメインは (私が知る限り) 照会されるタイプ (L2S タイプ) を確認する必要があるため、これは問題を引き起こします。

何か案は？

また、説明したくない理由により、nHibernate は問題外です.. :)

ウィキペディアによると、仕様パターンは、ブール論理を使用してビジネスロジックをチェーン化することにより、ビジネスロジックを再結合できる場所です。リストまたはコレクションからフィルタリングオブジェクトを選択することに関しては、DynamicLINQを使用すると同じことを実行できるように思えます。私は何かが足りないのですか？同様に考慮されるべき仕様パターンの他の利点はありますか？

編集：

LINQと仕様パターンの組み合わせについて説明している投稿をいくつか見つけました。

Linq仕様プロジェクト

Nicloas Blumhardt（Autofac dude）によるLinqを介した仕様パターンの実装

誰かがこの道を進んだことがあり、維持するのが複雑になりましたか？

私は、仕様を (オプションで) PHP に変換できる仕様パターンを PHP で作成する最善の方法を見つけようとしています。

私はいくつかの新しい方向性を模索しており、それらがどれだけうまく機能するかをテストしています. コードとアイデアは、私の頭の中ではまだ非常に不明確です。

最小限のインターフェイスは次のようになります。

リポジトリが sql データベースを隠している場合、仕様を sql に変換する必要があります。->toSQL() メソッドの追加はアドホックに思えます。仕様を変換するクラスもオプションですが、最終的に sql を生成するのはかなりのオーバーヘッドのようです。

アイデアを歓迎します。

私の質問は、仕様パターンをいつ使用するか、特定の SQL クエリをいつ使用するかです。

特定のパターンがコレクション全体を収集し、具体的な仕様を使用してフィルターを投稿する必要があることを理解しました。しかし、特定の SQL クエリの前での利点がわかりません。

そしてSQL/Hibernateでも同じ

処理するデータ量にもよると思います。

私は現在、新しいプロジェクトをセットアップしていますが、少し入力が必要ないくつかのことに遭遇しました。

これは私が考えているものです：

• 汎用リポジトリが欲しい

• リポジトリから IQueryable を返したくありません。

• クエリを仕様にカプセル化したいと思います。

• 仕様パターンを実装しました

• 簡単にテストできる必要があります

ここで少し行き詰まります。私の質問は、find メソッドを 1 つ以上の仕様で呼び出す最もエレガントな方法はどれかということです。

（流暢）：bannerRepository.Find().IsAvailableForFrontend().IsSmallMediaBanner()

または私の仕様でラムダとしてクエリを表現する

（ラムダ）：bannerRepository.Find.Where(banner => banner.IsFrontendCampaignBanner && banner.IsSmallMediaBanner)

それともまったく別の方法ですか？最も重要なことは、MVC フロントを実装する担当者がリポジトリを直感的に操作できるようにすることです。

私が達成したいと思っているのは、仕様を組み合わせることができるという点である程度の柔軟性を維持し、仕様で「フィルタリング」する経験を与えることですが、IQueryable をコントローラーにリークすることはありませんが、ISpecifiable のように、 Linqではなく仕様でクエリを変更します。しかし、この方法でクエリ ロジックをコントローラに漏らしただけでしょうか?

仕様パターンは、実装するクラスの階層を使用してISpecification<T>、型 T の候補オブジェクトが特定の仕様に一致する (= ビジネス ルールを満たす) かどうかを評価する方法を説明していることを知っています。

私の問題：実装したいビジネスルールは、いくつかのオブジェクト（顧客と契約など）を評価する必要があります。

私の二重の質問:

• これを達成するための仕様パターンの典型的な適応はありますか? ISpecification<T>仕様クラスによるの実装を削除し、メソッドで必要な数のパラメーターを取得することしか考えられませんisSatisfiedBy()。しかし、これを行うと、この仕様を他の仕様と組み合わせることができなくなります。

• この問題は私の設計の欠陥を明らかにしますか? (つまり、顧客と契約を使用して評価する必要があるものは、必要なすべての情報を含むサブスクリプションなどの別のオブジェクトで評価する必要があります) ?