2013-05-11 71 views
1

請我正確理解這一點。加載上下文

當您運行Web應用程序查看頁面並且創建上下文的實例時,該實例將所有數據庫日期加載到該實例中?

如果它確實不會佔用大量內存,那麼具有五年博客的博客可能會有1,500到2,000(或更多)的帖子,所有的評論標籤等都會有大量的數據。

那麼當你創建一個上下文的實例時會發生什麼?

回答

2

上下文只加載您請求的記錄,因此,當您第一次實例化一個記錄時,它將爲空,並且不會對數據庫執行任何查詢,直到您告訴它爲止。但是,通過它加載的任何實體都將(通常)緩存在上下文中,因此,每次運行查詢時它們都會使用越來越多的內存,並且隨着時間的推移可能會變得非常大。

由於這個原因,並且由於上下文實例化相對便宜,所以最好在實際需要時保持它們的活性,並在完成後立即處理它們。這是「工作單元」模式的一部分 - 基本上將每個操作集合作爲一個單元或事務使用一個新的上下文。

編輯補充:

如果你執行只讀查詢(即你只是想顯示的數據,你並不需要做出改變和將其保存到數據庫中),你可能會檢查非跟蹤查詢(例如,如果您使用的是DbContext/DbSetMergeOption.NoTracking屬性,則使用.AsNoTracking()方法,如果您使用的是ObjectContext/ObjectSet) - 這樣可以避免在上下文中緩存結果,從而提高性能並減少內存使用。

+0

謝謝你,已經有很大的幫助,我需要改變我的代碼,只打開上下文需要時,此刻一個頁面打開的情況下,當載荷,當它已經完成再關閉它這可能意味着我有一個非常行爲的大背景。謝謝 – 2013-05-11 11:03:46

+0

實際上,這是一種非常常見的做法 - 每頁請求一個上下文。除非你正在做很多處理,通常很好。它使用了一些記憶,但它也可以有類似的優勢,避免重複數據庫查詢,並希望整個事情是在具有相當快呢。真正的危險是如果你試圖爲整個應用程序共享一個上下文(以便它在請求之間持續存在) - 那麼它可能會嚴重臃腫,還有額外的併發問題,並且內存不會被釋放。 – 2013-05-11 16:00:33

+0

謝謝你在管理員添加和處理上下文時節省了一週的時間 – 2013-05-11 22:00:42