これは実際には EF Code First に関する質問ですが、OData のコンテキストによって違いが生じることがあります。質問は簡単です。基になる SQL Server テーブル/ビューには、(代理) 主キーとして Identity 列があります。また、ユーザーが使い慣れた一意の識別子を表す「コード」フィールドもあります。簡単な例: CarModel: Id = 3, Code = 'Ford'; データ注釈を使用して、ナビゲーション キーとして「コード」フィールドを使用してナビゲートする EF モードと OData を正常に作成しました。基になるテーブル/ビューにはそれらの列にインデックスがあるため、これは許容されます。しかし、Id 列をキーとして、モデルのナビゲーション プロパティとして使用したいのですが、応答には表示されません。おそらく、これが OData 部分の違いです。複雑な傍受や応答の再形成を行いたくないからです。列を「プライベート」または「内部」に設定すると、モデルの生成中にエラーがスローされます:「テーブル X にキーが定義されていません」
EF モデルで ID 列を定義することはできますが、それを OData エンティティ/応答の一部にすることはできませんか?
編集:
したがって、以下の私のコメントはまだ有効です。これは、ID/キー列にとっては良い考えではなく、それらを「隠す」ことでモデルを正しくコンパイルすることもできません。ただし、@mreyeros からのいくつかのリンクと、Vitek Karas からの social.msdn への投稿のおかげで、ここにいくつかのメモがあります。System.Data.Services 名前空間にはIgnorePropertiesAttribute
. モデルのプロパティを「非表示」にすることができます。ただし、Vitek が言うように、現在は ReflectionProvider でのみ機能し、EF では機能しません。(また、NuGet マネージド リリースを使用している場合は、正しいライブラリを参照していることを確認する必要があります。
つまり、流暢な構成 APIはEF/OData で機能します。
modelBuilder.Entity<Foo>().Ignore(f => f.Password);
ただし、応答でプロパティを非表示にするだけでなく、モデルとデータベースからも非表示にします (読み取り専用のクエリ モデルでは問題ない場合があります)。したがって、ナビゲーション キーを非表示としてマークすると、モデルはコンパイルされません。また、他のプロパティを非表示としてマークしても、それを QueryInterceptor で参照すると、例外がスローされます。