首先，在起初沒有使用倉儲模式時，本人在使用EF上下文基本都用了using標記，隨時使用隨時釋放，如下所示：
using(dbcontext con = new dbcontext()){
con.xxx......;
}
我們大家哦度知道，EF查詢跟蹤是存在數據緩存的，如果隨時釋放將無法利用緩存帶來的查詢速度提升。
同樣，EF緩存也面臨查詢出現髒數據的問題，各有利弊。
EF是默認開啓數據查詢緩存的，如果你需要開啓緩存後保證查詢數據的實時性，可用**AsNoTracking()**方法查詢最新數據，如下所示：
using(dbcontext con = new dbcontext()){
con.xxx.AsNoTracking().Tolist();
}
微軟文檔原文：https://docs.microsoft.com/en-us/ef/ef6/querying/no-tracking
在項目當中，倉儲模式大多數設計都是依賴DI注入來獲取上下文對象，那麼上下文的生命週期也就是由DI來控制，具體需要根據項目需求來設計。
個人而言，喜歡針對同一模型採用獨立的上下文實例對象來保證數據有效性，無論是EF緩存，還是惰性加載等機制，感覺都是爲MVC設計，且產生的髒數據問題並沒有一套完整的機制來處理，只能用某種方法來規避，而在前後端分離項目當中，往往緩存都是由Redis,Mongodb來負責DB和View之間的數據緩存來保證查詢效率，SQLServer2017之後也設計了DB緩存庫，貌似用的人並不是很多，具體性能不好評判。