一键导入
dbcontext-setup
Canonical DbContext setup and registration rules for EF Core. Load when creating or modifying DbContext classes or their DI wiring.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Canonical DbContext setup and registration rules for EF Core. Load when creating or modifying DbContext classes or their DI wiring.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Structure and rules for .NET projects using Clean Architecture with DDD. Use when the project has complex business domain, multiple use cases, need to test business logic in isolation, or when the system is enterprise, e-commerce, ERP, CRM, or any rich domain. Do not use for simple CRUDs without logic — prefer Vertical Slice in that case. For implementation details, load the required `backend/dotnet/orms/ef-core/*/SKILL.md` leaf skill(s) or your chosen data access skill.
Structure and rules for .NET projects using Hexagonal Architecture (Ports & Adapters). Use when the project has multiple input channels (API, CLI, message queue), need to test the domain in isolation, or when adapters change frequently. Do not use for simple CRUDs without logic — prefer Vertical Slice in that case. For implementation details, load the required `backend/dotnet/orms/ef-core/*/SKILL.md` leaf skill(s) or your chosen data access skill.
Structure and rules for .NET projects using Onion Architecture. Use when the project has a strong domain-centric focus with DDD, aggregate roots, and the Specification pattern. All dependencies point inward toward the domain core. Do not use for simple CRUDs without logic — prefer Vertical Slice in that case. For implementation details, load the required `backend/dotnet/orms/ef-core/*/SKILL.md` leaf skill(s) or your chosen data access skill.
Pure LINQ standards for .NET 10 projects. Covers language operators, query composition, projection patterns, filtering, grouping, and performance best practices over IEnumerable<T> and IQueryable<T>. Load when writing or reviewing LINQ expressions in any layer. DO NOT load expecting EF Core-specific methods (ToListAsync, AsNoTracking, Include, ExecuteUpdateAsync) — those belong to `backend/dotnet/orms/ef-core/query-best-practices/SKILL.md`.
Canonical rules for using AppDbContext DIRECTLY from application code (use cases / handlers) when the project's data-access pattern is Direct DbContext — no repositories, no UnitOfWork. Load when the chosen pattern is Direct DbContext and a use case reads or writes data. This is the counterpart to repository-usage; never load both for the same task.
Canonical EF Core query best practices for TemperAI: how each query method behaves, how to write performant queries, and the highest-value EF Core tricks. Load whenever a task writes EF Core queries — inside a repository OR directly against AppDbContext in a use case. Pattern-agnostic: the query rules are the same regardless of whether the project uses repositories or a direct DbContext.
| name | dbcontext-setup |
| description | Canonical DbContext setup and registration rules for EF Core. Load when creating or modifying DbContext classes or their DI wiring. |
| requires | ["backend-dotnet-csharp"] |
| produces | ["dbcontext","dbsets","configuration-registration"] |
On the DbContext name: the examples in this and every EF Core skill use
AppDbContextas an illustrative name for readability. The name is NOT mandated — a project may define one or several DbContexts (e.g. per bounded context or module). Use whatever name(s) the project defines, and apply these rules to whichever DbContext the task targets. Whatever name is chosen, keep every example internally consistent with it.
DbSet<T> names aligned with EF conventions and the chosen architectureDbContextAppDbContext as Scoped (the default of AddDbContext) — one instance per requestAppDbContext directly into application code when the data-access pattern is Repository + UnitOfWork — go through the repository abstraction. Direct injection into use cases is allowed ONLY when the pattern is Direct DbContext.DbSet<T> propertiespublic sealed class AppDbContext : DbContext
{
public AppDbContext(DbContextOptions<AppDbContext> dbContextOptions)
: base(dbContextOptions)
{
}
public DbSet<Product> Products => Set<Product>();
public DbSet<Order> Orders => Set<Order>();
public DbSet<Customer> Customers => Set<Customer>();
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfigurationsFromAssembly(typeof(AppDbContext).Assembly);
base.OnModelCreating(modelBuilder);
}
}
| Rule | Explanation |
|---|---|
sealed class | DbContext should be sealed |
DbSet properties | Prefer Set<TEntity>()-backed properties with names aligned to EF conventions |
ApplyConfigurationsFromAssembly | Auto-discovers IEntityTypeConfiguration<T> classes |
Never OnConfiguring | Provider and connection string belong in DI |
Registering AppDbContext is identical for both data-access patterns. What differs is whether you
also register repositories + UnitOfWork on top of it.
Use cases inject AppDbContext directly (see dbcontext-usage). Nothing else to register.
public static class DependencyInjection
{
public static IServiceCollection AddInfrastructure(
this IServiceCollection services,
string connectionString)
{
services.AddDbContext<AppDbContext>(options =>
options.UseSqlServer(connectionString));
return services;
}
}
Use cases inject repositories / IUnitOfWork, never the context (see repository-usage).
public static class DependencyInjection
{
public static IServiceCollection AddInfrastructure(
this IServiceCollection services,
string connectionString)
{
services.AddDbContext<AppDbContext>(options =>
options.UseSqlServer(connectionString));
services.AddScoped<IUnitOfWork, UnitOfWork>();
services.AddScoped<IProductRepository, ProductRepository>();
return services;
}
}
dotnet ef migrations add InitialCreate --project Infrastructure --startup-project Api
dotnet ef database update --project Infrastructure --startup-project Api
dotnet ef migrations remove --project Infrastructure --startup-project Api
// ❌ NEVER configure provider or connection string in OnConfiguring
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer("...");
}
// ❌ NEVER inline entity mappings in AppDbContext
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Product>(entity => { });
}