、、、などCustomerのオブジェクトを含むアプリケーションがあるとします。これらのオブジェクトは、データベース内のテーブルにマップされます。 EmployeeProductsCountyOfResidence
アプリケーションでは、以前に作成したストアド プロシージャを使用して、GUI を介してデータベースを検索できるようにしたいと考えています。
これは、コマンド パターンが役立つ場所ですか?
顧客と従業員の平均年齢を知りたいとしましょう。ストアド プロシージャに少し動的 SQL を使用すると、次のような状況を想像できます
FilterByAge(tableNameForDynamicSQL,typeWereFilteringAgainst)。またはのようなものFindPercentileRank(subject,tableName,type)。
GUI を呼び出し元として使用し、ストアド プロシージャをコマンドとして使用するというパラダイムは、私には十分に直感的に思えます。実務経験のある方から、こういう場合に使うパターンはありますか？
あなたが説明しているのは、コマンドパターンに非常によく似たQuery Object Patternのように聞こえますが、データまたはオブジェクトのクエリに固有のものです。
許可することを提案しているカスタマイズのレベルには、セキュリティとパフォーマンスに明確な潜在的な影響があります。たとえば、任意のテーブル名をストアド プロシージャに送信でき、そのストアド プロシージャが作成するクエリが SQL 用に適切に調整されていないテーブルに対して実行される場合、サービス拒否ベクトルを公開するリスクがあります。
かつて同様の要件がありましたが、検索パラメーターを変更する必要がありましたが、クエリの分類 (「ストアド プロシージャ」と呼ばれるもの) の戻り列は常に同じであることがわかりました。この情報を使用して、戻り値のセットごとに 1 種類のクエリ オブジェクトを作成しました。これらにより、すべての入力を完全にサニタイズする非常に柔軟なクエリが可能になりました。それはかなりうまくいきました。
余談ですが、クエリ オブジェクト タイプを作成する場合、ストアド プロシージャに限定されません。コードでパラメーター化された SQL を作成でき、実行可能な LINQ 式ツリーを構築することもできます。
通常、コマンド パターンは結果を返しません。通常、システムにコマンドを送信し、クラスがコマンドの意図をカプセル化できるようにします。
したがって、それはあなたの要件に正確には適合しません。あなたの質問は、クエリのカプセル化に関するものです。ただし、同じ方法でクエリをカプセル化できると思います。
Command の代わりにSpecificationパターンを見たいと思うかもしれません。Linq 自体は、(式を使用した) クエリの一種の仕様です。そのため、Linq to SQL や Entity Framework などを使用できる場合は、その多くが提供されます。