Indiko.Blocks.DataAccess.EntityFramework 2.7.7

Indiko.Blocks.DataAccess.EntityFramework

Entity Framework Core implementation for the Indiko data access abstractions.

What this package contains

This package provides the EF Core Repository<TEntity, TIdType, TDbContext> implementation and the EF UnitOfWork.

The default Manager<TDomainModel, TEntity, TIdType> implementation is defined in:

• src/Indiko.Blocks.DataAccess.Abstractions/Manager.cs

but it is wired by this package in DataAccessSetup<TDbContext> and used together with this repository at runtime.

Runtime wiring and execution model

DataAccessSetup<TDbContext> registers:

1. IRepository<TEntity, TIdType> → Repository<TEntity, TIdType, TDbContext>
2. IManager<TDomainModel, TIdType> → Manager<TDomainModel, TEntity, TIdType>
3. TDbContext and model-builder configuration

All Add/Update/Delete/Upsert methods queue state changes on the DbContext.
Persistence happens when UnitOfWork.Commit() or CommitAsync() calls SaveChanges() per context.

AsNotracking / AsNoTracking (important)

Most read APIs expose asNotracking (asNoTracking in selector APIs). When enabled:

• EF returns detached objects (AsNoTracking()).
• Reads are typically faster and cheaper.
• Returned entities are not tracked for later automatic persistence.

Use no-tracking for read-only flows. Use tracking when the returned entity is modified and saved in the same unit of work.

Current implementation notes

In Manager<TDomainModel, TEntity, TIdType>, these overloads currently force no-tracking to true when delegating:

• ReadByQueryAsync(..., bool asNotracking, ..., params string[] includes)
• ReadManyByQueryAsync(..., orderBy, ..., bool asNotracking, ...)
• ReadManyByQueryPagedAsync(..., orderBy, ..., bool asNotracking, ...)
• ReadManyByQueryPagedWithIncludesAsync(..., orderBy, ..., bool asNotracking, ..., includes)

So their asNotracking parameter is currently ignored by implementation.

Manager method analysis (domain-model layer)

Manager maps domain expressions/models to entity expressions/models and delegates to repository methods.

Repository method analysis (EF persistence/query layer)

Repository<TEntity, TIdType, TDbContext> is the concrete EF Core implementation over DbSet<TEntity>.

Error behavior summary

Common error sources across manager and repository methods:

1. Guard validation: null entities/models/collections (ArgumentNullException).
2. Single-result semantics: ReadByQuery* single-item APIs may throw InvalidOperationException when multiple matches exist.
3. EF/provider translation: unsupported expressions in filters/selectors/order/group operations.
4. Persistence/relational errors (on commit): FK violations, unique-index conflicts, optimistic concurrency issues.

Usage examples

1. Read-only query (recommended no-tracking)

var users = await manager.ReadManyByQueryAsync(
    x => x.IsActive,
    asNotracking: true,
    cancellationToken: ct,
    x => x.Orders);

2. Tracked entity for update in same unit of work

var entity = await repository.ReadByIdAsync(id, asNotracking: false, ct);
entity.Name = "Updated";
await repository.UpdateAsync(entity, ct);
await unitOfWork.CommitAsync(ct);

3. Paged, ordered read

var page = await repository.ReadManyByQueryPagedAsync(
    x => x.Status == Status.Active,
    x => x.CreatedAt,
    orderByAscending: false,
    page: 1,
    pageSize: 25,
    asNotracking: true,
    cancellationToken: ct);

4. Projection read model

var results = await manager.ReadByQueryWithSelectorAsync(
    x => x.IsActive,
    x => new UserListItem { Id = x.Id, Name = x.Name },
    asNoTracking: true,
    cancellationToken: ct);

Target framework and dependencies

• Target framework: .NET 10
• Core dependencies:
  • Indiko.Blocks.DataAccess.Abstractions
  • Microsoft.EntityFrameworkCore (10.x)
  • relational providers (SQL Server, PostgreSQL, SQLite, etc.)