我已搜查甚廣，並已經完全找不到任何好的樣品或如何調用使用ODataLib服務操作教程。我見過幾個告訴我如何獲得實體和實體集合，這很好，但爲了調用服務操作。使用ODataLib調用WCF數據服務業務運行和JSON
我幾乎肯定我需要使用除ODataEntry,ODataFeed或ODataNavigationLink對象以外的東西。我在JustDecompile中打開了這個庫，看到類似ODataAction和ODataFunction，但無法弄清楚如何使用它們。
我的需求是相當簡單：我需要調用WCF數據服務5.0服務業務，我需要使用JSON來做到這一點。
我也知道，即將WCF數據服務客戶端庫的版本將會支持JSON但不幸的是我有一個像昨天的代碼這件事。另外，出於絕望的考慮，我甚至嘗試使用Mark Stafford's JSON light sample來實現RC版本（gasp），但並沒有真正理解它是如何工作的。
任何幫助或方向將非常感激！ （尤其是如果這出現在屏幕上，馬克！）
謝謝！ Ĵ
爲客戶ODataLib和WCF數據服務（這取決於ODataLib）之間的選擇往往歸結爲需要進行控制。如果您的用例很簡單，而且您需要最常用的功能，那麼WCF DS可能非常適合。如果您需要高級功能或精確控制有效負載的讀取方式，ODataLib可能會更好。所有這一切，Vitek已經概念性地介紹瞭如何使用ODataLib讀取服務操作。
WCF DS將使版本5.1中的閱讀JSON Light變得更容易。我將在本週的某個時候對此進行博客，但是您引用的示例是您需要爲此RC執行的操作。我放在一起的樣本中只有一個新呼叫 - context.Format.UseJson(Func<Uri,ModelResolverResult>)的呼叫。讓我們先談談爲什麼這個電話是必要的。 OData（至少在微軟的世界中）可以很好地打字。 $metadata是OData描述它正在使用的數據模型的一個很好的例子。使用Atom payload甚至是JSON詳細負載，大部分類型的信息都在負載中傳輸。使用JSON Light的目標是儘可能多地去除「傳輸」有效載荷中的元數據。
如果元數據在帶內不可用，則必須使其帶外可用。這是UseJson電話簽名背後的基本要求。實質上，每當WCF DS需要元數據時，它都會查找給定URI的模型。如果它找不到該模型，它最終會將元數據全部撥出。我們希望搶先一步，因爲它會使有效載荷膨脹。我們可以通過告訴WCF DS如何提前解決模型來搶佔它。這是大部分樣本正在做的事情。
通過邏輯樣品散步（是的，我知道有一些其他的優化，可能已經進行了 - 樣品多爲可讀性優化）：
XmlReader呼叫到EdmxReader.TryParseEdmxReader.TryParseEdmxReader.TryParse
ModelResolverResult包裝希望這是有道理的返回。如果沒有，我很想聽聽爲什麼我可以使博客文章更清晰。請記住，當我們將這些位發佈到生產環境時，這將變得更簡單。
ODataLib不知道（而且是不應該知道），它的閱讀服務操作的響應。唯一的問題，如果你想讀什麼有效載荷類型。
這取決於服務操作返回的內容。如果它返回單個條目，那麼使用ODataLib就像讀取單個條目有效載荷（例如〜/ Products（0））一樣，因爲連線格式將相同。如果服務操作返回實體集合，則將其讀取爲feed。
如果服務操作返回了一個基本的或複雜的值，你可以使用ODataMessageReader.ReadProperty。我知道該方法的名稱有點誤導，但這又是因爲屬性有效載荷（如〜/ Products（0）/ Name）和返回原始類型或複雜類型的服務操作使用完全相同的有效載荷格式。在這種情況下，您應該忽略返回的屬性的名稱（它可能是服務操作的名稱）。
如果服務操作返回原始的或複雜的值的集合，你可以使用ODataMessageReader.CreateODataCollectionReader。這將返回ODataCollectionReader讀取器，您可以使用與ODataReader非常類似的方式。它報告的有趣的事情是有問題的集合的項目（這種情況下的API很容易理解）。
它不應該的問題是否需要閱讀ATOM或JSON，這是給你的API都是一樣的。
你所說的話非常有意義，而且實際上完全清除了樣本的含義。按照慣例，你已經設法降低到我的水平，我非常感謝你！ – Jason 2012-07-16 17:14:15