調節與管理的DbContext

現在我有這樣的背景下調節與管理的DbContext

namespace Dafoor_MVC.Models 
{ 
    public class DafoorDBContext : DbContext 
    { 
    public DbSet<Department> departments { get; set; } 
    public DbSet<Course> courses { get; set; } 
    public DbSet<Reply> replies { get; set; } 
    } 
}

這方面將變得很大，因爲我有大約40個型號，我想補充。

1是它有40個型號中的一個方面是一個好主意？

2 - 我希望所有用戶之間共享這種情況下，因爲我不想與查詢每次訪問數據庫如果記錄已經在一個範圍內，但是這會影響服務器的內存，所以如何我是否可以實現類似「最後一個對象用於處置或者沒有被調用的對象需要從上下文中處理一段時間」？我不想處理整個背景。

3如果2點沒有工作，我可以把用戶會話的上下文的實例，這樣的背景下將特定用戶而不是應用spicific

來源

2013-03-26 Moayad Al-sowayegh

是一個好主意，有在一個環境中的40個模型？

沒有什麼不對，如果他們都邏輯上屬於一起。

我想這方面的所有用戶

不，你不這樣做之間共享。您想爲每個單獨的HTTP請求實例化一個上下文，並在處理完HTTP請求之前將其處理掉。做不是緩存你的DbContext。

我可以把上下文的實例在用戶會話，這樣的背景下將特定用戶而不是應用spicific

你不應該緩存您的上下文。但是，您可以在Session中存儲使用上下文檢索的對象。如果不先將對象重新附加到新的上下文中，您將無法更新對象/對象圖。

UPDATE

這就是爲什麼的DbContext不應該被存放超出當前的HTTP請求：

One DbContext per web request... why?

來源

2013-03-26 18:18:27

問題是，我想使用的，而不是每次都命中數據庫服務器的內存。我想要find方法的第二個調用的優點。例如：例如：context.departments。find（someID）第一次使用select查詢，但第二次它會從上下文返回對象。 – 2013-03-26 18:26:44

然後，您需要將實例化對象存儲在會話（或緩存中，如果對象在所有用戶之間共享）。如果您嘗試緩存DbContext，則會發生非常糟糕的情況，特別是如果您嘗試在用戶間共享它時。 – 2013-03-26 18:34:26

1）沒有理由擔心在一個具有40+ DbSets上下文類。他們是簡單的集合，並且僅填充對象您目前使用

2）的DbContext和DbSet的實例成員不能保證線程安全的。我不建議單身的做法

3）你可以，但一定要處理數據庫併發異常正常

來源

2013-03-26 18:24:14 Moho

不，不要在用戶會話中存儲DbContext（點3）。請參閱http://stackoverflow.com/questions/10585478/one-dbcontext-per-web-request-why – 2013-03-26 18:35:53

沒有說這是個好主意;） – Moho 2013-03-27 00:57:17

調節與管理的DbContext

回答

相關問題