我們的 MySQL 資料庫中有大量表（大約 1800 個），并且大多數時候，每個開發人員都會創建自己的專案并添加一個包含必要表的背景關系，例如DbSets。我的一位同事建議創建一個專案，其中包含資料庫中的每個表并在每個專案之間共享。這會影響性能嗎？例如，它會在啟動時或運行積分期間減慢程式嗎？
uj5u.com熱心網友回復：
大型 DbContext 的初始化速度可能較慢，這是第一次使用時一次性的成本DbContext。這也是DbContext由于無效的架構配置而可能失敗的時候。DbContext您可以通過在服務/應用程式啟動時發出簡單的查詢來“加熱” 。例如：
// Check application DB version and warm the DbContext.
using (var context = new AppDbContext())
{
var dbVersion = context.AppConfig.Select(x => x.DbVersion).Single();
if (dbVersion < MinimumDbVersion)
throw new ApplicationException("The application database version is too low.");
}
資料庫有一個 AppConfig 表，其中包含配置設定，包括 DbVersion。基本上它可以是任何東西，加載配置設定，或者只是做一個Count用戶之類的。只要查詢執行，DbContext 的靜態初始化就會執行。
初始化所需的時間長度并沒有真正與宣告相關聯，而是與需要注意DbSet的物體總數相關聯。DbContext即使您有 100 個為它們定義的“頂級”物體DbSet，如果這些物體擴展到顯示與另外 1700 個物體的關系，那么這實際上與 1800 個 DbSet 的作業量相同。
有界背景關系是將物體拆分為“背景關系”的程序，每個背景關系都DbContext服務于系統的關鍵區域。這既減少了每個物體DbContext需要了解的物體數量，加快了初始化，也有助于更好地組織代碼以關注物體，甚至是與該區域相關的基礎資料的表示。物體可以在DbContext實體之間共享，但您應該確保只有一個人DbContext負責撰寫該物體。例如，您可以定義單獨的DbContext用于管理客戶和管理訂單的實體。訂單需要了解他們的客戶，但創建/更新客戶資訊是 CustomerDbContext 的責任，而不是 OrderDbContext。一種選擇是在 OrderDbContext 中使用諸如 CustomerSummary 物體之類的東西，以便在訂單背景關系中僅映射客戶的基本詳細資訊。理想情況下，DbContext 應該檢查 SaveChanges 上的插入/更新/洗掉更改跟蹤器中存在哪些物體型別，并在它們負責的物體型別以外的任何其他內容出現時拋出例外。
DbContext 的典型性能殺手通常歸咎于它們的大小，通常是允許 DbContext 實體生存時間過長并跟蹤太多物體。DbContext 知道的物體越多，它們就越容易最終跟蹤更多物體，而開發人員不會意識到實體打開時間過長。假設創建更大的背景關系“成本更高”，因此它被打開并傳遞/持續更長時間以避免感知成本，這會導致該實體的性能成本逐漸被跟蹤的實體膨脹。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/426630.html