仕様パターンを把握しようとしていて、少し混乱しています。特定の要件に役立つとは思えませんでした。複雑な仕様の拡張メソッドを好む場合、何が問題なのか知りたいですか? 例えば
public static class ProductExtensions
{
public static IQueryable<Product> InStocks(this IQueryable<Product> query)
{
return query.Where(p => p.InStock && !p.IsDeleted /*others goes here*/);
}
}
仕様化パターンを使用する代わりに、拡張メソッドで長い仕様をラップすると役立つことがわかりました。これの何が問題なのですか?
現在のアプローチに問題はありません。
非常に一般的な概念としての仕様パターンは、直交する概念を表すため、任意に適用できる組み合わせを扱う場合に意味があります。つまり、製品は電子レンジであり、重量も 5 ポンド未満です。
拡張メソッドは、常に一緒に表示される特定の条件をグループ化する場合に意味があります。つまり、製品の在庫があり、使用しやすい抽象化を形成するためにまだ製品を提供していますInStock。拡張メソッドの他の使用法は、多くの人が好む、最終的なクエリのより「流動的な」構成を可能にすることです。
両方の概念は相互に排他的ではなく、表現しようとしているものに対して、最も読みやすいコードになるものを使用する必要があります。
仕様パターンにより、プログラマーは実行時にデータを作成できます。これは、拡張メソッドを使用するよりも柔軟です。たとえばIQueryable<Product>、在庫がある製品と、先週売り切れた製品または注文されていないすべての製品が必要な場合はどうすればよいでしょうか? このようなクエリを作成するには、他の拡張メソッド全体を作成する必要がありますが、仕様パターンにより、単純な API を使用してクエリを作成できます。
IQueryable インターフェイスは、実際には仕様パターンの利点の一部を軽減しますが、私の意見では、IQueryable を使用してクエリを実行する方法と場所が開発者にとって常に明確であるとは限りません。これは、状況によっては問題になる場合とそうでない場合があります。
仕様パターンは、メソッド チェーンを介して条件のリストを作成し、その条件に対して 1 つのオブジェクトをチェックすることに重点を置いていますが、LINQ は、メソッド チェーンを介して変換クエリを作成することに重点を置いています。変換には基準 ( Where) リンクを含めることができますが、他のリンクも可能です。
仕様パターンが LINQ フレームワークによって確立されたパターンよりも「優れている」と考える理由は見当たらないので、あなたのアプローチが必ずしも「間違っている」とは限りません。ただし、メソッドはオブジェクトに対してのみ機能し、IQueryableオブジェクトに対しては機能しないことに注意してくださいIEnumerable。.InStocks()これは、SQL ステートメントに変換する方法がわからない LINQ to Entities などのテクノロジを使用する場合に制限を引き起こす可能性があります。