MiCake.EntityFrameworkCore 11.0.0-preview.12

MiCake.EntityFrameworkCore

Entity Framework Core integration for the MiCake DDD toolkit.

Overview

MiCake.EntityFrameworkCore provides EF Core support for MiCake:

• MiCakeDbContext - Enhanced DbContext with DDD support
• Repository Implementation - Auto-generated repositories
• Unit of Work - Transaction management with EF Core
• Store Conventions - Automatic entity configuration
• Domain Event Dispatch - Events triggered on SaveChanges

Installation

dotnet add package MiCake.EntityFrameworkCore

Quick Start

// Inherit from MiCakeDbContext
public class AppDbContext : MiCakeDbContext
{
    public DbSet<Order> Orders { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder); // Required!
        // Your configurations...
    }
}

Automatic Write Pipeline (Interceptors)

The write pipeline (write guard, transaction binding, and save lifecycle) is installed automatically for every DbContext registered in the container: the MiCake EF Core module registers an IDbContextOptionsConfiguration<TContext> configurator (ConfigureDbContext) that attaches the interceptors and the UseMiCake() options for you. No interceptor-install API call is required:

// Register the DbContext in the container — that is all.
services.AddDbContext<AppDbContext>(opt => opt.UseSqlite(connectionString));

• Permissive policy: a direct DbContext write without an ambient writable unit of work passes through with native EF Core semantics (e.g. implicit transaction). Guards, transaction binding, and lifecycle processing apply only when an ambient writable unit of work is active. MiCake never interferes with vanilla EF usage.
• Inside a unit of work, every write is guarded and transaction-bound: the first SaveChanges, ExecuteUpdate/ExecuteDelete, and raw SQL command executes inside the active unit-of-work transaction.
• Inheriting MiCakeDbContext is optional — plain DbContext types registered in the container get the same pipeline through the configurator. UseMiCake() remains the options-level entry for OnConfiguring scenarios.

Key Features

Repository and Persistence Ownership

Repositories never save or commit independently. Mutations are tracked on the stable context bound to the ambient unit of work; the unit of work is the sole persistence owner:

public class BookService
{
    private readonly IRepository<Book, Guid> _bookRepository;
    private readonly IUnitOfWorkManager _uowManager;

    public async Task ChangeAuthorAsync(Guid bookId, string author)
    {
        using var uow = await _uowManager.BeginAsync();

        var book = await _bookRepository.FindAsync(bookId);
        book.ChangeAuthor(author);

        // No repository save call: the unit of work commits the tracked changes
        await uow.CommitAsync();
    }
}

• AddAsync / UpdateAsync / DeleteAsync / DeleteByIdAsync only track changes.
• DeleteByIdAsync loads the aggregate into the stable unit-of-work context and uses tracked deletion, so audit, soft-delete, domain-event, and lifecycle behavior is preserved.
• Paging always produces a total order before Skip/Take by appending missing primary-key properties; keyless entities are rejected.

Explicit Physical and Bulk Operations

Operations that bypass aggregate lifecycle behavior (loading, audit mutation, soft deletion, domain events) are explicitly named and stay inside the unit-of-work transaction:

// Physical delete: bypasses aggregate lifecycle but is transaction-bound
var executor = provider.GetRequiredService<IEFCorePhysicalOperationExecutor<AppDbContext>>();
await executor.ExecuteDeleteAsync<Book>(b => b.PublishedAt < cutoff);

// EF bulk and raw SQL APIs are guarded and transaction-bound as well
await context.Books.Where(b => b.Price == 0).ExecuteUpdateAsync(s => s.SetProperty(b => b.Price, 1));
await context.Database.ExecuteSqlRawAsync("DELETE FROM \"Books\" WHERE ...");

Transactional Domain Events vs. Integration Events

• Domain events raised by aggregates are collected and dispatched inside the unit-of-work transaction during CommitAsync. A domain event handler failure aborts the commit and rolls back the whole unit of work.
• Integration events (cross-service notifications) must be published only after the transaction durably commits. Publish them after CommitAsync succeeds, or from the OnCommitted hook, never inside the transaction.

Migration Guide

Documentation

📚 Full Documentation

License

MIT License - see LICENSE