只讀搜索功能。存儲過程或IQueryable與POCO和Ef 4.0

Question

我們有一些搜索功能，可以從數據庫返回成千上萬的結果，儘管它只會獲取需要顯示到前10個記錄。當請求下一頁時，我們再次點擊db。它根據一組變量搜索我們的數據庫，然後可以改進這個搜索，這將導致另一個數據庫命中。查詢相當複雜。

我們一直在尋找與我們的整體架構相適應的不同方式。

第一種方法是使用存儲過程，可能會填充實體列表。這個存儲過程可能很快變得龐大而笨拙，但會有更好的性能。

第二種方法是將Linq to Entites或Entity SQL與實體框架4.0一起使用，並在我們概念層的代碼中創建查詢，並通過IQueryable填充POCO對象。這樣做的好處給我們的：

• 抽象：我們在應用程序的其他地方使用EF所以我們如果 可能喜歡的抽象模型 搜索。
• 類型安全，我們可以在鏈IQueryable的過濾器乾淨做我們想做的對象做oirentated方式

我們用這種方法主要關注的是性能。我們希望利用Parrlel LINQ to Entities，並且如果需要的話，可以在它上面扔更多的硬件。對於更清潔的開發模式而言，小的性能可謂不錯。

我們希望聽到人們對此的想法和建議......我們很多這些技術人員都是新手，所以想聽聽人們的經驗。

Answer 1

我已經做了一些性能測試，並在EF4.0中使用存儲過程來填充實體或複雜類型，這與性能與通過ADO.NET訪問的SP幾乎相同，因此我們將嘗試使用此方法。使用EF的內置查詢速度大約是速度的兩倍，所以我們要在這種性能嚴重的情況下使用SP。

Answer 2

你說的最終目標是性能。這意味着ADO.NET和直接的SQL給我。在它上面添加EF對於不需要狀態跟蹤，沒有更新能力，甚至不會使用所有結果的事情來說，是一項巨大的開銷。

針對數據庫編寫SQL，並儘可能地進行分頁。當你計劃把它們扔出去時，千萬不要拉扯1,000條條目。您也不能利用EF的服務器功能來處理像FTS或索引提示優化。您處於EF運行時的控制之下，這是通用的，並且不知道如何利用特定的硬件或服務器。

你還應該看看你知道的一些緩存層，用戶將要查詢下一個設置的時間百分比。獲得初始結果的兩倍並在後半部分回撥時緩存更便宜。否則，您會在某個時間點到期。