與反思提供商

WCF OData服務，我們需要提供一個活動Feed中的API（Facebook認爲），我們決定給OData的一個嘗試。我們使用.NET，因此我們選擇了WCF數據服務，但我們不使用實體框架（或任何其他ORM），因此我們將使用反射提供程序。因爲我們對檢索方法有複雜的業務邏輯，所以我們決定將它們公開爲服務操作。但是我們想要將Delete/Update和單個實體選擇作爲正常的OData REST資源公開。我的問題是我們如何能夠實施限制訪問的集合，但允許訪問單個實體（由關鍵要求）的反射提供數據源，可以刪除/ PUT/POST動詞，也允許訪問單個實體的子集（即服務/分類（1）/產品）。基本上，我只是想限制訪問基地集合（即服務/類別或服務/產品）與反思提供商

來源

2010-09-17 Stilgar

這裏沒有足夠大的答案。

有兩種設置，可以在裏面InitializeService使用（..）

config.SetEntitySetAccessRule("Feed", EntitySetRights.ReadSingle); 
config.SetEntitySetPageSize("Feed", 1);

遺憾的是沒有做你想要什麼：

EntitySetRights.ReadSingle限制你從一組只返回一個對象。因爲它不允許這個/ Categories（1）/ Products而失敗，並且它也允許/ Categories？$ filter = ...返回一行。
SetEntitySetPageSize將初始加載的數量限制在只有一條記錄的位置，但您可以按照$ skiptoken去獲取一條記錄的其餘數據，就像（1）它允許任意查詢不只是關鍵謂詞。

這使得你只有一個現實的選擇。訪問LINQ表達式並確定是否允許正在嘗試的內容。

由於您使用的是反射提供商，你基本上需要包裝從您的「語境」類返回的IQueryables，查找無效的查詢，傳遞他們之前。

不是爲暈倒善良。

如果您決定沿着這條路走下去，您會發現我的IQueryable wrapping example有用，您還應該查看Viteks blog post series on Data Service expressions。

希望這有助於

克斯（OData的項目經理）

來源

2010-09-17 18:27:57

非常感謝你。當我評估選項時，我實際上閱讀了包裝示例和自定義數據提供程序系列。實際上，第一種解決方案似乎並不那麼糟糕。我將不得不檢查有多少實體會收集孩子，還有多少人需要解決。我徘徊的另一件事是，如果在這種情況下拋出異常是可以的。這看起來很糟糕，但其他選項也不太好。包裝IQueryable看起來非常痛苦。老實說，我寧願放棄OData解決方案，並去做其他的服務類型。 – Stilgar 2010-09-17 22:18:14

與反思提供商

回答

相關問題