EF Core 2.1启动缓慢问题咨询：从EF6迁移后的性能疑问

Hey there! I’ve been right where you are—making the jump from EF6 to EF Core, excited about the performance gains, only to hit a frustrating slow startup wall with my generic repo and entity setup. Let’s walk through the most common issues and fixes tailored to your scenario:

1. Model Compilation Overhead (The Big One for 2.1) #

EF Core 2.1 lacks the pre-compiled model feature that later LTS versions (3.1+) offer. This means every time your app starts, EF has to compile your entire data model from scratch, which adds significant time—especially if you’ve got a complex setup with generic repos and base interfaces like IEntity.

Fixes: #

• Explicitly register entities in OnModelCreating: Instead of letting EF auto-scan assemblies for entities that implement IEntity, tell it exactly which entities to include. This cuts down on assembly scanning and model building time:

  protected override void OnModelCreating(ModelBuilder modelBuilder)
  {
      // Register each entity explicitly
      modelBuilder.Entity<Employee>();
      // Add other entities here if you have them
  }
  

• Ensure DbContext is properly injected: If you’re instantiating a new DbContext every time you use your generic repo, you’re forcing model compilation to happen multiple times. Register your DbContext as a scoped service in your DI container:

  services.AddDbContext<YourDbContext>(options => 
      options.UseSqlServer(Configuration.GetConnectionString("YourConnString")));
  

• Consider upgrading to an LTS version: If your project allows it, moving to EF Core 3.1 or later lets you use pre-compiled models with the dotnet ef dbcontext optimize command. This pre-generates the compiled model at build time, eliminating startup compilation entirely.

2. Generic Repository Pattern Pitfalls #

Generic repos can accidentally introduce startup overhead if not implemented carefully:

Fixes: #

• Avoid initializing repos during startup: If your app is creating instances of your generic repo when it boots up (e.g., for pre-loading data), this triggers model compilation early. Move any data access logic to the first request instead of startup.
• Simplify generic repo logic: If your repo is using complex expression trees or reflection to handle IEntity-derived types, this can slow down initial model setup. Stick to straightforward CRUD operations in the repo, and let EF handle the entity mapping.

3. Unnecessary Lazy Loading Proxy Generation #

If you’ve enabled lazy loading proxies in EF Core 2.1, EF has to generate dynamic proxy classes for your entities at startup, which adds overhead.

Fix: #

• Disable lazy loading if you don’t need it: Turn off proxy generation in your DbContext configuration:

  services.AddDbContext<YourDbContext>(options => 
      options.UseSqlServer(Configuration.GetConnectionString("YourConnString"))
             .UseLazyLoadingProxies(false));
  

  Only keep it enabled if you absolutely rely on lazy loading for your use case.

4. Assembly Scanning Bloat #

EF Core 2.1 scans all referenced assemblies to find entities, which can be slow if your project has lots of dependencies.

Fix: #

• Limit assembly scanning: When configuring your DbContext, specify exactly which assemblies to scan for entities instead of letting it scan everything:

  protected override void OnModelCreating(ModelBuilder modelBuilder)
  {
      // Scan only the assembly containing your entities
      modelBuilder.ApplyConfigurationsFromAssembly(typeof(Employee).Assembly);
  }
  

  This narrows down the scope of what EF needs to check during startup.

Start with the simplest fixes first—explicit entity registration and proper DbContext injection often resolve most startup slowness in EF Core 2.1. If you can swing an upgrade to a newer EF Core version, that’s the most impactful long-term fix for startup performance.

内容的提问来源于stack exchange，提问作者Krzysztof Skowronek