仮定: このソリューションは当面の間、常に MS、C#、.Net、SQL Server、Entity Framework であり、DAL、BLL などは外部ソースに渡されませんが、同じスイートの別のアプリケーションで使用される可能性があります。
A. Linq と IQueryable を使用してクエリ オブジェクト パターンを実装し、リポジトリや DAO の処理を忘れるべきですか?
B.パターンに適合するために何かを行う/実装する必要がありますか? これに関する方法の例はあまり見つかりませんでした。
テクノロジーとパターンの間で何かが欠けていると思います。Linq は、非常に便利な方法でデータを操作するためのある種の低レベルのテクノロジです。しかし、それはパターンではなく、パターンとは何の関係もありません。
一方、クエリ オブジェクト パターンを実装する場合 (非常に簡単なデータ クエリ機能を実装する必要があり、複数の方法でデータをクエリできる場合、これは非常に良い考えです)、Linq またはを使用して実装できます。それなし。それは完全にあなた次第です。また、linq 自体は、クエリ オブジェクトを実装するのに役立ちませんでした。
また、クエリ オブジェクトを使用してデータ アクセス レイヤーを実装することにしたとしても、それは Service や Repository パターンを使用する必要がないという意味ではありません。ほとんどの場合、特にリーチ クエリ機能を使用している場合は、両方を実装できるはずです。必要なすべてのメソッドを備えたサービスまたはリポジトリを実装するのは非常に難しいためです。
とにかく、複雑なプロジェクトでは、ユーザーが DAL コードの外部で IQueryable を使用できるようにすると、深刻な問題が発生します。簡単な例: データの一部が変更され、ID フィールドに ID1 フィールドが含まれるようになりました。データをクエリする方法が 1 つである場合は、コードを 1 か所変更するだけですが、どこでも IQueryable を使用できるようにする場合は、ID が使用されているすべての場所を見つけて ID1 に置き換える必要があります。
また、クエリ機能が非常に貧弱な場合は、クエリオブジェクトやリポジトリなどはほとんど必要ありません。アクティブなレコードパターンで十分です。