在the msdn documentation有不直接綁定控件對象查詢的建議:綁定到實體框架
我們建議您不要直接將控件綁定到的ObjectQuery。 而是將控件綁定到Execute方法的結果。
我也讀過一些關於SO的答案,推薦它,也不要綁定到模型本身的實例。儘管如此,我仍然無法找到爲什麼它不被推薦,因爲迄今爲止我所做的所有測試似乎都能正常工作。
任何人都可以闡明爲什麼我不應該使用這些對象作爲綁定的原因嗎?
在the msdn documentation有不直接綁定控件對象查詢的建議:綁定到實體框架
我們建議您不要直接將控件綁定到的ObjectQuery。 而是將控件綁定到Execute方法的結果。
我也讀過一些關於SO的答案,推薦它,也不要綁定到模型本身的實例。儘管如此,我仍然無法找到爲什麼它不被推薦,因爲迄今爲止我所做的所有測試似乎都能正常工作。
任何人都可以闡明爲什麼我不應該使用這些對象作爲綁定的原因嗎?
對於這個問題:「爲什麼我不應該將控件綁定到的ObjectQuery」:
引用from here:
爲了確保數據源是最新的,則可能需要執行 再次使用Execute方法查詢。這會將控件 綁定到新的ObjectResult。
如果你不叫Execute
,什麼是顯示在您的用戶界面可能會達不到最新的相比有什麼查詢被執行後,實際返回。當數據庫發生更改時,綁定當然不會自動更新。
觀點二:
我們建議您不要直接將控件綁定到的ObjectQuery。 而是將控件綁定到Execute方法的結果。在 中綁定這種方式可以防止在綁定期間多次執行查詢。
如果按照the link below that info,他們給出的解釋:
我們建議您不要直接將控件綁定到的ObjectQuery。 而是將控件綁定到Execute方法的結果。 在 中綁定這種方式可以防止在綁定過程中多次執行查詢。
您不希望在綁定過程中執行查詢。我不希望綁定更新觸發數據庫查詢,但我不知道。此外,我發現綁定到實體直接導致其他問題。通過保持這些對象,你還需要保持ObjectContext。通常,應該儘可能縮短ObjectContext的長度,最好在使用塊中。
如果你用EF或任何種類的LINQ進行延遲執行,或者你更新了UI中的對象,並且你的數據上下文超出了範圍,那麼整個事情就會爆炸。 – 2012-07-05 13:28:59