WCF データ サービスのリポジトリ パターンの実装に問題があります。要約すると、必要なリポジトリにプラグ可能なモデルを利用するクライアント アプリケーション内でリポジトリ パターンを使用しようとしています。根本的な問題は、私のリポジトリ インターフェイス IRepository が、それが格納するアイテムのインターフェイス タイプ バリアントについてしか認識できないことです。これは、注文の Data Service 実装からクライアント アプリケーションを抽象化することです。
IRepository<IOrder> : IQueryable<T>
一般に、この概念は、Data Services が関与するまで問題なく機能します。現在、NuGet の Data Services v5.4 を使用しています。リポジトリで ToList() のような単純なアクションを実行すると、すべてが正常に機能し、変換によって結果が OData サービスからの注文のリストに変換されます。ただし、orderby を実行しようとすると、クエリ式がより複雑になり、クエリ可能な型のインターフェイス バリアントのインスタンスを作成しようとするため、戻り値の型を設定できません。つまり、Order の代わりに IOrder のインスタンスを作成しようとします。
repository.OrderBy(order => order.Id).ToList(); // Fails
ただし、クライアントレベルでは、キャストを使用して型を強制すると機能します...
repository.Cast<Order>(order => order.Id).ToList(); // Suceeds
明らかに、これは切断された型のマントラに反しています。クライアント アプリケーションは、将来 OData を切り替えたい場合に備えて避けたいデータ サービス ライブラリからの強力な型 'Order' を認識しなければならないからです。
次に、タイプを解決するためのメソッドのハンドルを取得できる Data Service Client 側の Context クラスに出くわしましたが、私の場合、何らかの理由で解決が呼び出されませんでした。
その後、私が見始めたのは ExpressionVisitors でした。これは、この混乱から抜け出すためのチケットであると今でも信じています。これは、クエリが強い型を返しますが、インターフェイスの種類。
空のシェル ExpressionVisitor 実装を使用する場合など
MyVisitor : ExpressionVisitor
これは、データ サービス以外のクエリ (クエリ可能なリストなど) では問題なく機能しますが、データ サービス リポジトリ パターンのクエリでは、(少なくとも私にとっては) 役に立たない「ノードを縮小する必要があります」というメッセージが表示されます。私が推測しているのは、式ツリーのビジターが、データ サービス クエリにカスタム化されたノード タイプにヒットし、それに対して何をすべきかわからないということです。しかし、何か別のことをするように言われない限り、ExpressionVisitor は単にツリーにあるものをコピーすると思いましたか?
とにかく、私が求めているのは、この ExpressionVisitor を使用してクエリの戻り値の型を OData クエリに置き換えるにはどうすればよいですか? 既存の Data Services Expression Visitor を探してみましたが、見つかりません。クライアント側のデータ サービスでインターフェイス タイプのクエリからクエリを生成する必要がありますが、同じ名前の厳密な型が返されます。