update 2?

和是不是web api無關

update 2? 是說vs 2012 update 2? 我還在用VS 2010...

不確定缺了什麼DLL或是設定,因為是從一般的web專案開始改的...

www.asp.net/web-api/over...

blogs.msdn.com/b/webdev/...

This feature requires either:
The ASP.NET and Web Tools 2012.2 Update or
The Microsoft ASP.NET Web API OData NuGet package

不是已經寫了嗎？

我已經好久沒碰vs2010了，Web Tools 2012.2 update ... vs2010能裝嗎？

而且現在很多東西都用到 .net 4.5 的技術，最好是開 .net 4.5 來試，比較不會有問題。

沒人說要在vs2010上裝web tools 2012.2 update啊...

甚麼都用最新的,最方便的,當然就不會有甚麼大問題...也不會發現會有甚麼問題...msdn論壇上的小白特多大概也是因為這樣吧...因為大家都習慣了一鍵安裝,一個指令就幫他弄完一些設定,所以也就不知道這過程中到底發生了甚麼...

咦，nuget.org/packages/Micro...
在VS2010裡裝這個NuGet還是不行嗎？看dependency想說.net framework 4.0應該ok才是。不過我也不敢確定就是了

我在vs2010裡裝了odata的package後,雖然有看到OData的dll了,也是沒有效果...現在電腦重灌中,明天才能試了.

ajunlee: 我本來很想試試看OData, 順便看能不能導進實務上，不過就像之前講的，感覺後面如果沒接EF等ORM 作延遲執行，就少了戲劇化的效果了

我是有用EF,不過用OData只是想要試試看查詢分頁的部分能省多少工,不過這部分也還是在做POC而已,前端是用knockout.js來接資料.

ajunlee: 我也覺得分頁跟filter，可以提供超多方便的。開發上也會簡潔很多。
基本上只要透過attribute控制好security權限，接著幾乎API都只要回丟整個完整的data/entity model，其他的就交給呼叫端自行決定。

光不用開這麼多 signature, API 接口，不用維護那堆毛，加上是吃request時的url，才決定Query的筆數跟條件，一整個是美好的願景！

沒錯,我原本想法就是提供RESTful的架構跟介面,這樣不管是用web或是app,都可以由一致的方式來接,不過我現在還在弄web版,使用的也只有windows驗證,到時候app如果要接的話,授權驗證的部分可能就有得搞了...

ajunlee: Orz 還是比我們強大多了

終於可以了...原來還要加個[Queryable]屬性在function前...除了要宣告回傳物件為IQueryable,還有return時要使用.AsQueryable()外,還要加個Queryable的attribute才行...用2010的話,裝odata的package就可以了.

@@

一定要IQueryable啊...我記得這樣才能走expression

我一開始還以為，因為要IQueryable，所以後面一定要接EF，否則要自訂實作IQueryable介面，要作的事情實在太多了

後來知道 IEnumerable可以轉成IQueryable，但這樣只有做到一半，因為若只是把IEnumerable轉成IQueryable，而不是用ORM，效能還是好不起來。

因為不可能拋出完整的model，只在controller層作filter, 這樣DB太操了

我一開始就是用IQueryable跟AsQueryable(),只是少加了[Queryable]的attribute在function前...

對於不拋出完整model的部分...我是另外定義要拋出的data object...不確定有沒有更好的做法,不過會用EF只是為了要省去一些開發時間...

ajunlee: 喔喔喔

有機會的話，在請孤影大哥分享一下吧 很有興趣！

我如果在OData中選用EF, 反而是為了performance XD

hatelove: 有機會在一起交流一下.

這個話題完全插不上話

BillChung: 簡單的說，OData可以讓你從同一個url上（也就是同一個方法），去篩選、排序你要的結果。

我也插不上話 XD

BillChung: 例如以前為了分頁，我們需要開一個function的signature，要額外傳入pagesize, pageindex，後面程式才能取得該頁資料回傳。
現在url只要打localhost/Products?$top=...
就可以取得第21~30筆資料。

而我們function內容，只要回傳整個IEnumerable的結果 (要轉成IQueryable)，而不用先寫死Top()跟Skip()

程式碼看起來是回傳整個Product的集合，但是當url是/Products?$filter=Category eq 'Toys'
則會在服務被呼叫時，自己補上 .Where(x=>x.Category == "Toys") 再回傳。

後面如果再掛上Entity Framework之類的ORM框架，具備延遲執行的效果的話，則會在API被呼叫時，才組出request端所需要的SQL執行。
因此只會撈該分頁的資料，或是filter上的條件會被加入Where condition。

這樣DB也只會執行跟回傳該次request所希望執行的資料存取動作。

我們就不需要為了那堆Filter, Take, Skip, OrderBy 額外開很多API或function，只為了不同的條件或signature。
以上，是我大略上的理解。

簡單的說就是為了減少寫重複的code