从EF迁移至EF Core：如何正确使用using语句？

Hey David, let's walk through your questions one by one to get your DbContext setup aligned with EF Core best practices.

1. 解决using语句中DbContext的构造参数问题 #

Your xxxDbContext requires a DbContextOptions<xxxDbContext> parameter in its constructor, which is the standard approach in EF Core (replacing the old EF6无参构造模式). There are two recommended ways to handle this in your manager class:

方法一：通过依赖注入（推荐） #

This is the cleanest approach, as it leverages EF Core's built-in support for dependency injection and keeps your configuration centralized.

First, update your manager class to accept DbContextOptions<xxxDbContext> via constructor injection:

public class CaseManager
{
    private readonly DbContextOptions<xxxDbContext> _dbOptions;

    // Inject options through DI
    public CaseManager(DbContextOptions<xxxDbContext> dbOptions)
    {
        _dbOptions = dbOptions;
    }

    public List<Case> GetAllCases(int databaseId)
    {
        // Use the injected options to create a context instance in using
        using (var myContext = new xxxDbContext(_dbOptions))
        {
            return myContext.CasesListing
                .Where(w => w.databaseID == databaseId)
                .OrderBy(o => o.CustomerName)
                .ToList();
        }
    }
}

Then register your DbContext and manager class in your application's service configuration (e.g., Program.cs for .NET 6+):

var builder = WebApplication.CreateBuilder(args);

// Register DbContext with your connection string
builder.Services.AddDbContext<xxxDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("YourConnectionStringKey")));

// Register your manager class as a scoped service
builder.Services.AddScoped<CaseManager>();

方法二：手动构建Options（仅特殊场景使用） #

If you can't use DI (e.g., in a console app without a service container), you can manually build the options:

public List<Case> GetAllCases(int databaseId)
{
    var options = new DbContextOptionsBuilder<xxxDbContext>()
        .UseSqlServer("YourFullConnectionString")
        .Options;

    using (var myContext = new xxxDbContext(options))
    {
        return myContext.CasesListing
            .Where(w => w.databaseID == databaseId)
            .OrderBy(o => o.CustomerName)
            .ToList();
    }
}

Note: This approach hardcodes your connection string, which is not ideal for production or multi-environment setups.

2. EF Core中是否支持无参构造？ #

Yes, you can add a parameterless constructor to your xxxDbContext, but it's not recommended for most scenarios. If you need it, you'll have to override OnConfiguring to provide database configuration when the parameterless constructor is used:

public class xxxDbContext : DbContext
{
    // Parameterless constructor (not recommended)
    public xxxDbContext() { }

    public xxxDbContext(DbContextOptions<xxxDbContext> options) : base(options) { }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        // Only configure if no options were passed via constructor
        if (!optionsBuilder.IsConfigured)
        {
            optionsBuilder.UseSqlServer("HardcodedConnectionString");
        }
    }

    public DbSet<JobsList> JobListingss { get; set; } 
    public DbSet<Clients> ClientListings { get; set; } 
    public DbSet<Engineer> EngineerListing { get; set; } 
    public DbSet<Case> CasesListing { get; set; } 
}

The main issue with this approach is that it ties your DbContext to a specific connection string, making it harder to test, switch environments, or reuse across different parts of your app. Stick with DI whenever possible.

3. 业务方法的最佳放置位置：独立类还是DbContext分部类？ #

Always put business logic in separate service/manager classes, not in DbContext partial classes. Here's why:

• Single Responsibility Principle: The DbContext's job is to manage database connections, entity mappings, and change tracking. It shouldn't be responsible for business rules or query logic.
• Testability: Independent service classes are easier to unit test—you can mock the DbContext or its options without needing a real database.
• Maintainability: Keeping business logic separate keeps your DbContext lean and makes it easier to modify or extend logic without touching data access code.

If you add business methods to DbContext partial classes, you'll end up with a bloated context that does too many things, leading to messy code and harder debugging.

内容的提问来源于stack exchange，提问作者David B