Organize Large Models with IEntityTypeConfiguration, Assembly Scanning, and Validation

Learning outcomes

By this point, ServiceHub mapping contains table/column facets, ignored members, and encapsulation rules. Leaving all of that in one OnModelCreating method makes ownership, review, merge conflicts, and testing progressively worse. EF Core provides IEntityTypeConfiguration<TEntity> and assembly scanning to modularize model construction—but modularization introduces its own ordering and discovery rules that must be explicit.

1. Move WorkOrder mapping out of the context

using Microsoft.EntityFrameworkCore;using Microsoft.EntityFrameworkCore.Metadata.Builders;using ServiceHub.EfLab.Domain;namespace ServiceHub.EfLab.Data.Configurations;public sealed class WorkOrderConfiguration    : IEntityTypeConfiguration<WorkOrder>{    public void Configure(EntityTypeBuilder<WorkOrder> builder)    {        builder.ToTable("work_orders");        builder.HasKey(x => x.Id);        builder.Property(x => x.Id)            .HasColumnName("work_order_id");        builder.Property(x => x.CustomerName)            .HasColumnName("customer_name")            .HasMaxLength(120)            .IsRequired();        builder.Property(x => x.Summary)            .HasField("_summary")            .UsePropertyAccessMode(PropertyAccessMode.Field)            .HasColumnName("summary")            .HasMaxLength(400)            .IsRequired();        builder.Property(x => x.Priority)            .HasColumnName("priority");        builder.Property(x => x.OpenedUtc)            .HasColumnName("opened_utc");        builder.Ignore(x => x.DisplayLabel);    }}

The context can now focus on model composition rather than every entity detail.

protected override void OnModelCreating(ModelBuilder modelBuilder){    modelBuilder.ApplyConfiguration(new WorkOrderConfiguration());}

Explicit application gives deterministic, reviewable order. It is an excellent default when the model is modest or when some configurations intentionally layer over others.

2. Assembly scanning removes repetitive ApplyConfiguration calls

protected override void OnModelCreating(ModelBuilder modelBuilder){    modelBuilder.ApplyConfigurationsFromAssembly(        typeof(WorkOrderConfiguration).Assembly);}

EF locates IEntityTypeConfiguration<T> implementations in the assembly. A predicate can restrict which types are applied.

modelBuilder.ApplyConfigurationsFromAssembly(    typeof(ServiceHubContext).Assembly,    type => type.Namespace == "ServiceHub.EfLab.Data.Configurations");

3. Assembly-scanned configuration order is undefined

Microsoft's model-building documentation explicitly warns that the order in which ApplyConfigurationsFromAssembly applies configurations is undefined. Therefore scanned configuration classes must not rely on “A runs before B” to resolve conflicting values.

public sealed class WorkOrderLengthA : IEntityTypeConfiguration<WorkOrder>{    public void Configure(EntityTypeBuilder<WorkOrder> b)        => b.Property(x => x.CustomerName).HasMaxLength(80);}public sealed class WorkOrderLengthB : IEntityTypeConfiguration<WorkOrder>{    public void Configure(EntityTypeBuilder<WorkOrder> b)        => b.Property(x => x.CustomerName).HasMaxLength(120);}

If both are discovered by scanning, relying on one to “win” is invalid design because order is undefined. Even if a particular build appears stable, reflection/discovery details are not your configuration-order contract.

4. Configuration classes discovered by scanning need usable constructors

The current EF Core model-building documentation notes that assembly scanning instantiates configuration types with parameterless constructors; types whose constructors require parameters are skipped and a warning is logged. That is a strong signal that configuration classes should normally be deterministic metadata definitions, not service-locator objects that pull request/environment state into model construction.

public sealed class WorkOrderConfiguration(IConfiguration configuration)    : IEntityTypeConfiguration<WorkOrder>{    public void Configure(EntityTypeBuilder<WorkOrder> builder)    {        // Runtime/environment state is now coupled to model construction.    }}

If a configuration genuinely requires constructor arguments, instantiate it manually and apply it explicitly. Before doing that, ask whether the argument itself violates the stable-model/cache assumptions from Lesson 1.

5. Scanning has trimming/NativeAOT implications

The EF Core 10 API for ApplyConfigurationsFromAssembly is annotated RequiresUnreferencedCode because it searches arbitrary assembly types. That matters for trimming and NativeAOT scenarios where reflection-discovered types can be removed unless preserved. Chapter 17 returns to compiled models/startup/NativeAOT performance. For now, treat assembly scanning as a runtime discovery mechanism with deployment implications, not a zero-cost syntactic convenience.

6. Organize by entity/aggregate ownership, not by API method

src/ServiceHub.EfLab/├─ Domain/│  └─ WorkOrder.cs└─ Data/   ├─ ServiceHubContext.cs   ├─ Configurations/   │  └─ WorkOrderConfiguration.cs   ├─ ServiceHubContextFactory.cs   ├─ ServiceHubSeed.cs   ├─ ServiceHubDiagnostics.cs   └─ Migrations/

Do not create separate global files named MaxLengths.cs, ColumnNames.cs, and Requiredness.cs that force reviewers to assemble one entity's mapping mentally from many places. A focused configuration per entity/aggregate is usually easier to reason about.

7. Validate the composed model programmatically

public static void ValidateServiceHubModel(ServiceHubContext db){    var entity = db.Model.FindEntityType(typeof(WorkOrder))        ?? throw new InvalidOperationException("WorkOrder missing from model.");    if (entity.GetTableName() != "work_orders")        throw new InvalidOperationException("Unexpected WorkOrder table mapping.");    var customer = entity.FindProperty(nameof(WorkOrder.CustomerName))!;    if (customer.GetMaxLength() != 120 || customer.IsNullable)        throw new InvalidOperationException("CustomerName mapping drifted.");    var summary = entity.FindProperty(nameof(WorkOrder.Summary))!;    if (summary.GetMaxLength() != 400 || summary.IsNullable)        throw new InvalidOperationException("Summary mapping drifted.");}

These assertions validate EF metadata after all conventions/annotations/configurations have composed. They catch accidental mapping drift before a migration reaches deployment. Add relational provider integration tests as the model grows; metadata checks alone do not prove SQLite/SQL Server/PostgreSQL DDL equivalence.

8. Migration stability is part of model-organization quality

Moving equivalent Fluent calls from OnModelCreating into IEntityTypeConfiguration should not create a schema migration if the finalized model is truly unchanged. Use that as a refactoring acceptance test.

# Before refactor: working tree clean and current migrations applied.# Move mapping to WorkOrderConfiguration, then:dotnet tool run dotnet-ef -- migrations add VerifyConfigurationRefactor --project src/ServiceHub.EfLab# Inspect generated migration. If there are unexpected operations, the model changed.# If the migration is empty and was only a probe, remove it:dotnet tool run dotnet-ef -- migrations remove --project src/ServiceHub.EfLab

Do not automatically commit an empty probe migration. The point is evidence that a code-organization refactor preserved model semantics.

9. Hands-on lab: refactor to configuration classes and prove no drift

1. Move all WorkOrder mapping from ServiceHubContext.OnModelCreating into WorkOrderConfiguration.
2. First apply it explicitly with ApplyConfiguration; run the app and metadata validation.
3. Generate a probe migration and confirm the refactor did not alter the model/schema.
4. Switch to ApplyConfigurationsFromAssembly with a namespace predicate.
5. Run metadata validation again.
6. Add a second deliberately conflicting configuration class, observe the model result/warning risk, and then remove it; do not rely on scan order.
7. Optionally add a configuration class with a required constructor parameter and observe the logged skip warning during scan; then remove it.
8. Record trimming/NativeAOT warning implications in the lab notes even if the current course app is not published with trimming.

Verification checklist

• ServiceHubContext is small and composes configuration rather than containing every mapping.
• Exactly one authoritative class configures each WorkOrder facet.
• Assembly scanning does not rely on configuration order.
• Metadata validation passes.
• A refactor-only migration probe has no unexpected schema operations.
• No configuration constructor pulls per-request state into model building.

10. Chapter 03 production judgment and bridge

Chapter 03 converts EF model building from implicit convention behavior into a reviewable metadata pipeline. ServiceHub now has an observable finalized model, deliberate relational facets, a clear configuration-precedence policy, encapsulated persistence where useful, and modular configuration classes with validation.

Before production, keep Microsoft EF packages aligned at the current supported patch, run migration/provider integration tests on the actual production engine, avoid runtime-dependent model shapes unless deliberately engineered, treat assembly-scan order as undefined, and preserve configuration types under any trimming/AOT deployment strategy. Chapter 04 builds on this model foundation with keys, indexes, value generation, shadow state, and concurrency-sensitive property semantics.

Authoritative references

• Creating and Configuring a Model — IEntityTypeConfiguration and ApplyConfigurationsFromAssembly guidance, including undefined application order
• ModelBuilder.ApplyConfiguration — explicit deterministic configuration application
• ModelBuilder.ApplyConfigurationsFromAssembly — assembly scanning, predicate, and trimming annotation
• IEntityTypeConfiguration<TEntity> — entity-configuration interface
• Managing Migrations — migration review and model-change workflow
• .NET 10 downloads — current .NET 10 runtime/SDK checkpoint