「機能が提供されているからといって、それが良いアイデアであるとは限らない」という警告を事前に理解してください...
見た目から、OData 準拠の署名では IQueryable を返す必要があります。
例えば:
[Queryable]
public IQueryable<MyModel> Get()
{
return _repo.GetAll().AsQueryable();
}
ただし、最近およびそれほど最近ではない過去の多くの記事では、IQueryable を次のように説明しています。
- 漏れやすい
- ' Causing Heavy Lifting ' 例: ユーザーがテーブル全体をつかむことができるようにする
- クエリ自体を大幅に変更できるため、セキュリティとスケーリングの問題があります
- 遅延実行による問題も発生する可能性があります (クエリ可能な性質のため)
私の質問は:
IQueryable と OData の機能が上記の問題を上回っていると思いますか?
答える際に、私は人々が次のことについて話すことを期待しています:
- なぜですか、そうでないのですか?
- いつ使用すればよいですか?
- 一部の WebAPI 呼び出しでのみ使用しますか?それともすべての WebAPI 呼び出しで使用しますか?
- IEnumarable オブジェクトではない個々のモデルはどうですか?
...そういうもの。
背景: 上記の理由だけでなくお願いします。また、OData はツールボックスのツールとしてではなく、"業界標準" として販売されているためです。したがって、これを実装すると、WebAPI 呼び出し (私が現在働いている場所) のリターンが根本的に変わります。独自の IResult リターン シグネチャ (これは非常に便利です) から、問題があると思われる IQueryable に移行する必要があります (ただし、有用になる可能性もあります)。
IRESULT の例:
少なくとも、返品の署名は大幅に変更されます。そして、「C インスタンス」を「IQueryable インスタンス」に変更すると、OData を実装する WebAPI 呼び出しが機能しないと言われました (これは理にかなっています)。
public interface IResult<C>
{
[JsonProperty(PropertyName = "hasErrors")]
bool HasErrors { get; }
[JsonProperty(PropertyName = "errors")]
IList<String> Errors { get; }
[JsonProperty(PropertyName = "instance")]
C Instance { get; set; }
}