工作角色中的實體框架的DbContext生存期

我有一個工作者角色，每秒都會對數據庫做一些工作。工作角色中的實體框架的DbContext生存期

工作人員啓動時初始化DbContext並在工作人員的整個生命週期中使用它可以嗎？

db連接是如何處理的？如果數據庫脫機並重新聯機，該怎麼辦？我仍然可以使用上下文嗎？

2015-01-04 daramasala

太寬泛，太模糊。首先有兩個問題。那麼，第一個很大程度上取決於你在工作者角色中做什麼，多少數據，多長時間。對於第二個問題，您應該查看與Entity Framework的連接彈性。 – 2015-01-04 23:26:31

@GertArnold問題是關於在輔助角色中使用單個'DbContext'實例。其他問題是我在這方面擔心的事情。「多久」 - 「整個職工的一生」。這意味着從VM啓動到VM關閉，不是嗎？「連接恢復能力」 - 你是否說連接丟失是一個暫時的故障，將由重試邏輯處理？ – daramasala 2015-01-05 05:54:30

我的建議是創建，使用和銷燬每個操作的上下文......不要拘泥於此。我曾經擔心起初是因爲我不知道創建DbContext的代價有多昂貴，答案不是很多。

如果你試圖保持重用的DbContext情況下，你也會遇到問題（非常快），因爲它的內部狀態的車型將開始報告衝突對已加載的對象的版本（更新等等）之前

來源

2015-01-15 01:29:11

我接受這個答案，因爲它是正確的，但也請參閱我的答案中的擴展解釋。 – daramasala 2015-01-18 07:17:47

本文建議在OnStart（）中設置DbContext並在Run（）中使用：https：//azure.microsoft.com/en-gb/documentation/articles/cloud-services-dotnet-get-started/#create-the - 應用 - 從劃傷。這並不是說這是正確的，但僅供參考 – 2016-03-16 22:59:31

該文章涉及的是我能看到的Azure雲存儲，而不是本地磁盤上的Entity Framework。在一些處理網絡通信的系統上，它可能比初始化連接並保持打開狀態更可取，但這取決於需要完成的握手數量（即HTTP不以這種方式工作）。所以我認爲你們應該小心，不要在這裏混淆概念，因爲骨幹（和操作）在兩者之間會有很大的不同。乾杯，保羅 – 2016-03-17 22:20:58

就我目前所知，主要的DbContext抽象是工作單元。

DbContext在需要時打開和關閉數據庫連接（即在context.SaveChanges()），因此數據庫連接與上下文的範圍無關。

這樣看來，我現在認爲要決定DbContext實例的範圍，你需要考慮你的工作單元和它在內存中管理的實體。

例如，我的問題，通常使用遍及工人的生命週期單上下文實例就沒有任何意義，因爲：

通常你會在每個角色中調用不同的實體工作。在這種情況下，上下文將需要將這些實體加載到內存中。
加班時，上下文將管理越來越多的內存中的實體，這會導致性能問題（因爲它掃描圖尋找變化和事情）並最終導致內存問題。
將實體長時間保存在內存中會增加上下文中實體與db中實際數據之間不一致的可能性。解決這些不一致可能會降低性能。

總而言之，在輔助角色的整個生命週期中使用相同的DbContext實例可能是錯誤的。

根據您正在實施的工作單位來決定DbContext的範圍。

來源

2015-01-15 12:36:53 daramasala

工作角色中的實體框架的DbContext生存期

回答

相關問題