你如何處理查詢表/數據與實體框架？

我建議，實體框架應該是足夠聰明，不會產生加盟國家/地方 - 表

DbContext.Users.Include(u => u.Country.Select(c => c.Place))

取而代之的是EF應該從內存中獲取數據。

如何處理查詢數據與實體框架？

來源

2012-05-24 rafe

你的問題是什麼？明確。 –

如果查找表很小，很可能已經從RDBMS端的內存中獲取。過早優化通常不是一件好事，所以微軟決定不參與。 – dasblinkenlight

因此，您希望EF在訪問之前急切地將所有查找表加載到內存中？這聽起來有點凌亂和沉重。（如果查找有更新，怎麼辦？如何同步？）如果您使用Pks，加入查詢表很快。如果你需要在內存中加載查找表，你仍然需要在你的linq查詢中對包含表數據的代理對象進行連接。我沒有硬數據，但我看不出兩種技術在性能上有很大差異。如果有的話，Linq的例子可能會變慢。我的經驗法則是：如果兩種技術在速度和收益方面相似，那麼使用不太複雜且易於維護的技術（在您的情況下，使用Include（））。

來源

2012-05-24 15:49:27

感謝您的回答！我認爲代理對象，加載，在我的情況下，國家和地方，甚至可能是狀態，應該從緩存（鍵/值字典）比聯接（期望linq到實體SQL生成）更快地定義。我認爲每次加載來自DB的數據都是無意義的（這些表在運行時永遠不會更新）。來自nhibernate的二級緩存的工作還是如此？ – rafe

如果他們永遠不會在運行時更新，我看不到緩存表的巨大問題。不過，我不指望你會看到非常大的性能提升，如果有的話。編寫一個快速的實驗控制檯應用程序來衡量這兩種技術的性能。一個總是去數據庫加入，另一個緩存起來，然後運行一堆連接。做10,000次迭代，看看性能提升是否足以進行架構變更。請記住 - 不成熟的優化是所有邪惡的根源。 –

你如何處理查詢表/數據與實體框架？

回答

相關問題