Entity Framework Core interview questions covering value conversions, inheritance mapping, query filters, interceptors, auditing and architecture.
Open a question for the full answer, code and interview guidance.
A value converter transforms a property value between the CLR representation used by the application and the provider value stored in the database. Common uses include storing enums as strings, wrapping primitive values in domain types, or converting application-specific formats. Converters affect persistence representation; they do not replace validation or encryption design.
A custom converter defines expressions for converting a model value to a provider value and converting the provider value back to the model type. It is useful for strongly typed value objects and specialized storage formats. The conversion should be deterministic and compatible with query translation requirements.
A ValueComparer tells EF Core how to compare, snapshot, and hash property values when ordinary CLR equality is insufficient. It is especially relevant for mutable collections or custom value types used with value conversion. Without an appropriate comparer, EF Core may fail to detect in-place changes correctly.
Owned entity types model values that conceptually belong to another entity and do not have an independent lifecycle in the domain. Examples include Address or Money details owned by a Customer or Order. They can be mapped into the owner's table or another table depending on configuration and EF Core capabilities.
Complex types model structured values that are part of an entity rather than independent entities with their own identity. They are useful for reusable value-oriented structures such as addresses. Unlike normal entities, they are not independently tracked by identity. Exact mapping capabilities depend on the EF Core version and provider.
Table splitting maps multiple entity types to the same database table, typically when the entities share the same primary-key value and represent different parts of one row. It can support specialized domain models or legacy schemas. Because configuration is more complex, use it only when the model benefits clearly from the separation.
Entity splitting maps properties of one entity across multiple tables. It can be useful with legacy schemas or when one conceptual entity is physically divided across tables. It increases mapping complexity and should be used when the database design requires it rather than as a default modeling technique.
EF Core can map .NET inheritance hierarchies to relational tables using supported inheritance strategies. Common strategies include table-per-hierarchy, table-per-type, and table-per-concrete-type. Each has different query, storage, and performance characteristics, so the mapping should match both the domain and expected workload.
TPH stores an entire inheritance hierarchy in one table and uses a discriminator to identify the concrete type. It usually requires fewer joins and is EF Core's common inheritance approach, but the table can contain nullable columns that apply only to particular derived types.
TPT maps properties declared on each type to a separate table. A derived entity may require joins across the base and derived tables when queried. The schema can look normalized, but complex hierarchies can produce more expensive SQL. Performance should be measured with realistic queries before selecting TPT.
TPC maps each concrete type to its own table, with inherited properties repeated in each concrete table. It can avoid joins for queries targeting one concrete type, while polymorphic queries may require combining multiple tables. It trades schema duplication for different query characteristics.
Global query filters automatically add a predicate whenever a mapped entity type is queried. They are commonly used for soft deletion or tenant isolation. Because the filter is implicit, developers must understand when it applies and when IgnoreQueryFilters is intentionally used.
A tenant identifier can be incorporated into a global query filter so normal queries return only rows belonging to the current tenant. This reduces the chance of forgetting a tenant predicate in individual queries. The tenant value must come from a trustworthy context, and write operations and administrative bypasses require equally careful isolation.
Soft delete marks a row as deleted instead of physically removing it. A property such as IsDeleted or DeletedAtUtc records the state, while a global query filter can hide deleted rows from ordinary queries. The design must address uniqueness, related entities, auditing, retention, and intentional restoration or permanent deletion.
An interceptor receives callbacks around EF Core operations and can observe or alter selected behavior. Interceptors exist for areas such as database commands, connections, transactions, and SaveChanges. They are useful for cross-cutting persistence concerns but should remain focused so database behavior does not become difficult to understand.
A SaveChangesInterceptor can execute logic before or after SaveChanges and when saving fails. Typical uses include auditing metadata, domain-event coordination, diagnostics, or enforcing persistence-level conventions. Avoid placing core business decisions in an interceptor because hidden side effects can make the application difficult to reason about and test.
DbCommandInterceptor can observe or influence database commands executed by EF Core. It can support diagnostics, timing, command tagging, or specialized infrastructure behavior. Interceptors run on a critical data-access path, so expensive work should be avoided and sensitive SQL data should be handled carefully.
Auditing can record who changed data, when it changed, and sometimes the before/after values. A common approach inspects ChangeTracker entries during SaveChanges or uses a SaveChanges interceptor. Audit records should be written consistently and should avoid leaking sensitive values that should not be retained.
Shadow properties exist in the EF Core model without corresponding CLR properties. They can hold persistence-only values such as foreign keys, audit metadata, or legacy columns while keeping them out of the domain class. They are accessed through Entry APIs or EF.Property in queries. Excessive use can make the model harder to discover and maintain.
Backing fields allow EF Core to persist data through fields rather than requiring public property setters. This supports encapsulated domain models where state changes occur through methods. EF Core can discover some conventional backing-field names or fields can be configured explicitly.
EF Core can map non-public members when they are part of the model configuration. This lets domain entities protect invariants while persistence still stores required values. Mapping private state should remain understandable to maintainers and should not make ordinary querying or migration behavior unnecessarily obscure.
Both features centralize cross-cutting data-access behavior. Query filters can enforce recurring predicates such as tenant or soft-delete conditions, while interceptors can observe persistence and database operations. Their main risk is invisibility: a developer reading a local query may not realize extra behavior is being applied. Document them, test bypass scenarios, and keep the rules narrowly scoped.
Not necessarily. DbContext already provides unit-of-work behavior and DbSet provides repository-like access. A custom repository can be useful when it expresses meaningful domain queries, hides multiple data sources, or creates a deliberate application boundary. A generic repository that merely duplicates every EF Core method can add abstraction without adding value.
DbContext belongs to the persistence/infrastructure concern, while application logic should depend on abstractions or use cases appropriate to the architecture. Some designs expose repository interfaces; others allow application handlers to depend on a narrow persistence abstraction. The goal is to keep business rules testable and avoid leaking persistence concerns unnecessarily, not to add layers for their own sake.
Use advanced mapping features only when they solve a concrete domain or database problem. Prefer clear conventional models when possible, and document global filters, converters, interceptors, inheritance strategies, and unusual mappings because they affect behavior outside the immediate code location.