Why RLS Matters

Defense Against Code Bugs: Application-level filters are fragile. One forgotten WHERE tenant_id = @id and you've leaked data across tenants. RLS enforces protection at the database level, catching what your code misses.

Cleaner Code: Without RLS, every query needs explicit tenant filtering scattered across your codebase. RLS centralizes this logic in the database, eliminating repetitive security code.

Multi-Tenant Security: For SaaS applications sharing databases, RLS delivers single-schema simplicity with isolation guarantees approaching physical separation. One connection pool, one database, strict tenant boundaries.

Implementation Guide

1. Configure PostgreSQL

Enable RLS and create policies for your table:

CREATE TABLE projects (
    id SERIAL PRIMARY KEY,
    tenant_id UUID NOT NULL,
    name TEXT NOT NULL,
    description TEXT
);

ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

-- Filter reads, writes, updates, and deletes by tenant
CREATE POLICY tenant_isolation ON projects
    FOR ALL
    USING (tenant_id = current_setting('app.current_tenant')::UUID)
    WITH CHECK (tenant_id = current_setting('app.current_tenant')::UUID);

2. Extract Tenant Context

Pull the tenant ID from authenticated user claims:

public interface ITenantProvider
{
    string? GetCurrentTenantId();
}

public class JwtTenantProvider : ITenantProvider
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    public JwtTenantProvider(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    public string? GetCurrentTenantId()
    {
        return _httpContextAccessor.HttpContext?.User
            .FindFirst("tenant_id")?.Value;
    }
}

3. Create EF Core Interceptor

Set the session variable when connections open:

public class RlsConnectionInterceptor : DbConnectionInterceptor
{
    private readonly ITenantProvider _tenantProvider;

    public RlsConnectionInterceptor(ITenantProvider tenantProvider)
    {
        _tenantProvider = tenantProvider;
    }

    public override async Task ConnectionOpenedAsync(
        DbConnection connection,
        ConnectionEndEventData eventData,
        CancellationToken cancellationToken = default)
    {
        var tenantId = _tenantProvider.GetCurrentTenantId();

        if (!string.IsNullOrEmpty(tenantId))
        {
            using var command = connection.CreateCommand();
            command.CommandText = $"SET LOCAL app.current_tenant = '{tenantId}';";
            await command.ExecuteNonQueryAsync(cancellationToken);
        }

        await base.ConnectionOpenedAsync(connection, eventData, cancellationToken);
    }
}

4. Wire Up Dependency Injection

builder.Services.AddHttpContextAccessor();
builder.Services.AddScoped<ITenantProvider, JwtTenantProvider>();
builder.Services.AddScoped<RlsConnectionInterceptor>();

builder.Services.AddDbContext<ApplicationDbContext>((serviceProvider, options) =>
{
    var interceptor = serviceProvider.GetRequiredService<RlsConnectionInterceptor>();

    options.UseNpgsql(connectionString)
           .AddInterceptors(interceptor);
});

5. Write Clean Controllers

Your controllers need zero tenant filtering logic:

[ApiController]
[Route("api/[controller]")]
[Authorize]
public class ProjectsController : ControllerBase
{
    private readonly ApplicationDbContext _context;
    private readonly ITenantProvider _tenantProvider;

    public ProjectsController(
        ApplicationDbContext context,
        ITenantProvider tenantProvider)
    {
        _context = context;
        _tenantProvider = tenantProvider;
    }

    [HttpGet]
    public async Task<ActionResult<List<Project>>> GetProjects()
    {
        // RLS filters automatically - no WHERE clause needed
        return Ok(await _context.Projects.ToListAsync());
    }

    [HttpPost]
    public async Task<ActionResult<Project>> CreateProject(CreateProjectRequest request)
    {
        var tenantId = _tenantProvider.GetCurrentTenantId();
        if (string.IsNullOrEmpty(tenantId))
            return Unauthorized();

        var project = new Project
        {
            TenantId = Guid.Parse(tenantId),
            Name = request.Name,
            Description = request.Description
        };

        _context.Projects.Add(project);
        await _context.SaveChangesAsync();

        return CreatedAtAction(nameof(GetProject), new { id = project.Id }, project);
    }
}

Critical Gotchas

Use SET LOCAL, Not SET: SET LOCAL limits variables to transaction scope, preventing leakage across pooled connections. Using plain SET is dangerous with connection pooling.

Index Your Tenant Columns: RLS policies execute on every query. Without proper indexes on tenant identifier columns, performance will suffer.

Beware Superusers: PostgreSQL superusers bypass RLS by default. Use dedicated application roles with limited privileges.

Test Thoroughly: Verify policies work as expected by attempting cross-tenant access with different user contexts.

The Bottom Line

RLS moves security from application code into the database where it belongs. Your queries stay simple, your data stays isolated, and bugs in your filtering logic won't expose sensitive information. For multi-tenant applications, it's the difference between hoping your code is perfect and knowing your database enforces boundaries automatically.

Data-heavy back-end services—imports, ETL routines, validation workflows—often begin life as one long method full of if/else blocks. Soon the logic becomes brittle, difficult to test and almost impossible to extend. The Fluent Pipeline DSL pattern offers a clean escape hatch: break the work into single-purpose steps (handlers), chain them with a fluent mini-language, and let the compiler guarantee that every piece fits.

Below we explore the pattern using the Why → How → What structure.

WHY

A Fluent Pipeline solves these issues by:

• Isolating each action into a self-contained handler.

• Composing handlers in a clear, linear pipeline.

• Enforcing type safety so that incompatible steps fail at compile-time.

• Exposing a DSL that reads like a specification of the business process.

HOW

Contract per step

 public interface IHandler<in TIn, TOut>
{
    Task<TOut> HandleAsync(
        TIn input,
        ProcessingContext ctx,
        CancellationToken ct = default);
}

Minimal engine

public sealed class PipelineEngine
{
    private readonly IServiceProvider _sp;
    public PipelineEngine(IServiceProvider sp) => _sp = sp;

    public Task<TOut> RunAsync<TH, TIn, TOut>(

        TIn input, ProcessingContext ctx, CancellationToken ct = default)

        where TH : class, IHandler<TIn, TOut>

        => _sp.GetRequiredService<TH>().HandleAsync(input, ctx, ct);
}

Fluent builder + DSL

public sealed class PipelineBuilder<TCur>
{
    /* … holds engine, current Task, context, token … */

    public PipelineBuilder<TNext> Then<TH, TNext>()

        where TH : class, IHandler<TCur, TNext>     { /* chain logic */ }

    public Task<TCur> FinishAsync() => _currentTask;

}

public static class PipelineDsl
{
    public static PipelineBuilder<TOut> Execute<TH, TIn, TOut>(…);
    public static PipelineBuilder<TNext> Then<TH, TCur, TNext>(…);
}

Handlers are plain services

public sealed class XmlValidation : IHandler<string, string> { … }
public sealed class XmlParsing   : IHandler<string, ParsedDto> { … }
public sealed class SaveToDb     : IHandler<ParsedDto, ImportSummary> { … }

Orchestrate with MediatR (or any caller)

 var summary = await _engine
 .Execute<XmlValidation, string, string>(xml, ctx)
 .Then<XmlParsing,   string, ParsedDto>()
 .Then<SaveToDb,     ParsedDto, ImportSummary>()
 .FinishAsync();

The pipeline is lazy—nothing runs until await. Cross-cutting concerns (logging, metrics, retries) can wrap each Task centrally without touching individual handlers.

WHAT – Benefits & Typical Use-Cases

External analogy – Image processing in Python

A similar pattern is common in data science pipelines, e.g., Pillow handlers: validate → resize → convert → upload. Each step receives an image object, transforms it, and the fluent chain expresses the workflow as readable code—exactly the same idea we bring to .NET.

Use the Fluent Pipeline DSL whenever you have a sequence of business transformations that should be easy to extend, test, and reason about. Your future self—and your teammates—will thank you.

We will achieve this using a powerful combination: the declarative state management of NgRx SignalStore and Angular's built-in Route Resolvers.

The What: The Problem of In-Component Data Fetching

First, let's define the problem we are solving. The most common pattern for fetching data in Angular is to do it within a component's ngOnInit lifecycle hook.

1. A user clicks a link to navigate to /products.

2. The Angular Router immediately destroys the old component and renders the ProductsComponent.

3. The ProductsComponent's view appears, but it's empty. It shows a loading spinner or a blank space.

4. Inside ngOnInit, a service method is called to fetch the products from an API.

5. Once the HTTP request completes, the data is populated, and the component's view updates to display the products.

This sequence creates a noticeable "flicker" or "layout shift" where the user sees an incomplete view before the final content is displayed. Our goal is to change this sequence so that the data is ready before the component even exists.

The Why: The Superiority of the Resolver Pattern

Why should we move data fetching logic out of the component and into the routing layer? The benefits are significant and lead to a more robust and professional application architecture.

1. Flawless User Experience: The primary advantage. The user navigates, and the new view appears instantly complete and fully rendered. The wait time is spent during the route transition itself (which can be indicated by a global progress bar, like on YouTube or GitHub), not within a half-rendered component.

2. Smarter Architecture, "Dumber" Components: Components become simpler and more focused. Their only job is to display the state that is given to them. They become agnostic of how or when the data is fetched. This greatly simplifies their logic and makes them easier to test and reuse.

3. Centralized Data Fetching Logic: By using a Resolver, you tie the data requirement to the route itself. This centralizes your data-loading logic within your routing configuration, making it clear what data is needed for which part of your application.

4. Robust Error Handling: What if the API call fails? With a Resolver, you can gracefully cancel the navigation. The user stays on the current page, and you can display a global error notification. This is much cleaner than navigating to a broken page that is stuck in a permanent loading state.

The How: A Step-by-Step Implementation

Let's build this pattern step-by-step using SignalStore and a Route Resolver.

Step 1: The SignalStore with a Robust Asynchronous Method

First, we need a SignalStore with a method that both performs the data fetch and returns an Observable. The Angular Router will use this Observable to wait for the operation to complete.

// src/app/todos.store.ts
import { inject } from '@angular/core';
import { patchState, signalStore, withMethods } from '@ngrx/signals';
import { withEntities, setAllEntities } from '@ngrx/signals/entities';
import { tapResponse } from '@ngrx/operators';
import { Observable } from 'rxjs';
import { TodosService, Todo } from './todos.service'; // Your HTTP service

export const TodosStore = signalStore(
  { providedIn: 'root' },
  // Use withEntities for powerful collection management
  withEntities<Todo>(),
  withMethods((store, todosService = inject(TodosService)) => ({
    // This is the method we will call from our Resolver.
    // Crucially, it returns an Observable that the router can wait for.
    loadTodos(): Observable<Todo[]> {
      return todosService.getTodos().pipe(
        // tapResponse is a clean way to handle side effects like state updates
        tapResponse({
          // On success, update the store's state with the fetched entities
          next: (todos) => patchState(store, setAllEntities(todos)),
          // You can also handle errors here without breaking the stream
          error: console.error,
        })
      );
    },
  }))
);

Step 2: Create the Route Resolver Function

A Resolver is a simple, exportable function that acts as a "gatekeeper" for a route. The router executes this function and waits for the Observable it returns to complete before activating the route.

// src/app/todos.resolver.ts
import { inject } from '@angular/core';
import { ResolveFn } from '@angular/router';
import { TodosStore } from './todos.store';
import { Observable } from 'rxjs';

// The resolver's return type is now Observable<any>
export const todosResolver: ResolveFn<any> = () => {
  const store = inject(TodosStore);

  // Call the store method AND RETURN the resulting Observable.
  // The router will now pause navigation and wait for this to complete.
  return store.loadTodos(); 
};

Step 3: Configure the Route

Now, we connect our todosResolver to a specific route in our application's routing configuration.

// src/app/app.routes.ts
import { Routes } from '@angular/router';
import { TodosComponent } from './todos/todos.component';
import { todosResolver } from './todos.resolver';

export const routes: Routes = [
  {
    path: 'todos',
    component: TodosComponent,
    // Add the `resolve` property here
    resolve: {
      // The key 'todos' is arbitrary. The value is our resolver function.
      todos: todosResolver,
    },
  },
  // ... other routes
];

Step 4: The Simplified Component

This is the payoff. Look how clean and simple our TodosComponent becomes. It has no ngOnInit for fetching data, no loading state management, and no complex logic. It trusts that when it is rendered, the TodosStore already contains the necessary state.

// src/app/todos/todos.component.ts
import { Component, inject } from '@angular/core';
import { TodosStore } from '../todos.store';

@Component({
  selector: 'app-todos',
  standalone: true,
  // imports: [/* Add necessary Angular imports here, like @for */],
  template: `
    <h2>My Todos</h2>

    <!-- 
      No need for @if (store.isLoading())!
      By the time this component renders, the data is already here,
      because the resolver waited for the loadTodos() call to complete.
    -->

    <ul>
      @for (todo of store.entities(); track todo.id) {
        <li>{{ todo.title }}</li>
      } @empty {
        <li>No todos found.</li>
      }
    </ul>
  `,
})
export class TodosComponent {
  // Simply inject the store and read from it.
  readonly store = inject(TodosStore);
}

Conclusion

By combining NgRx SignalStore with Angular's Route Resolvers, you can fundamentally improve your application's architecture and user experience. This pattern moves data-fetching logic to a more appropriate location, simplifies your components, and provides a seamless, professional navigation flow that users expect from high-quality applications. The next time you find yourself adding a loading spinner inside a component, consider promoting that logic to a Resolver and let the Angular Router do the heavy lifting for you.

What?

Domain events are a design pattern in Domain-Driven Design (DDD) used to capture and broadcast significant state changes in your domain model. In the context of C# with Entity Framework Core 8 and MediatR, domain events enable you to decouple the core logic of your application from side effects, such as notifications or external system updates.

MediatR is a popular library in the .NET ecosystem that facilitates CQRS (Command Query Responsibility Segregation) and mediator patterns. It helps to manage interactions between objects, reducing dependencies and promoting a clean, maintainable codebase. MediatR uses handlers to process requests, such as commands, queries, and notifications, allowing for better separation of concerns.

Why?

Separation of Concerns: By using domain events, you ensure that your core domain logic remains clean and focused on business rules, while other concerns (like notifications or logging) are handled separately.

Decoupling: Domain events help to decouple different parts of your application, promoting a more modular and maintainable architecture.

Testability: With domain events, you can more easily test your core domain logic without worrying about side effects, improving the overall testability of your application.

How?

To implement domain events using C# with Entity Framework Core 8 and MediatR, follow these steps:

Capturing Domain Events

1. Define a Basic Interface for Domain Events:

Create an interface IDomainEvent that inherits from MediatR's INotification. This interface will represent the domain events.

    namespace RecipeManagement.Domain
    {
        using MediatR;

        public interface IDomainEvent : INotification { }
    }

2. Create a Base Entity Class:

Develop a base entity class that all your entities can inherit from. This class will include:

• A list of IDomainEvent called DomainEvents to capture messages we want to publish.

• A primary key property called Id for entity identification.

• A method QueueDomainEvent to add events to the DomainEvents list.

    namespace RecipeManagement.Domain
    {
        using System;
        using System.Collections.Generic;
        using System.ComponentModel.DataAnnotations;
        using System.ComponentModel.DataAnnotations.Schema;

        public abstract class BaseEntity
        {
            [Key]
            public Guid Id { get; private set; } = Guid.NewGuid();

            [NotMapped]
            public List<IDomainEvent> DomainEvents { get; } = new List<IDomainEvent>();

            public void QueueDomainEvent(IDomainEvent @event)
            {
                DomainEvents.Add(@event);
            }
        }
    }

3. Define and Publish the Domain Event:

Create a domain event class that implements IDomainEvent. Raise this event in your domain model.

    public class OrderPlacedEvent : IDomainEvent
    {
        public int OrderId { get; }
        public DateTime OrderDate { get; }

        public OrderPlacedEvent(int orderId, DateTime orderDate)
        {
            OrderId = orderId;
            OrderDate = orderDate;
        }
    }

    public class Order : BaseEntity
    {
        public DateTime OrderDate { get; private set; }

        public void PlaceOrder(DateTime orderDate)
        {
            OrderDate = orderDate;
            QueueDomainEvent(new OrderPlacedEvent(Id, orderDate));
        }
    }

4. Save and Dispatch Domain Events:

Customize your DbContext to intercept the SaveChanges and SaveChangesAsync methods and dispatch the domain events after the changes are committed by encapsulating the dispatch logic in a method called DispatchDomainEvents.

    public class AppDbContext : DbContext
    {
        private readonly IMediator _mediator;

        public AppDbContext(DbContextOptions<AppDbContext> options, IMediator mediator)
            : base(options)
        {
            _mediator = mediator;
        }

        public override int SaveChanges()
        {
            OnBeforeSaving().GetAwaiter().GetResult();
            return base.SaveChanges();
        }

        public override async Task<int> SaveChangesAsync(CancellationToken cancellationToken = default)
        {
            await OnBeforeSaving();
            return await base.SaveChangesAsync(cancellationToken);
        }

        private async Task OnBeforeSaving()
        {
            await DispatchDomainEvents();
        }

        private async Task DispatchDomainEvents()
        {
            var domainEventEntities = ChangeTracker.Entries<BaseEntity>()
                .Select(po => po.Entity)
                .Where(po => po.DomainEvents.Any())
                .ToArray();

            foreach (var entity in domainEventEntities)
            {
                var events = entity.DomainEvents.ToArray();
                entity.DomainEvents.Clear();
                foreach (var entityDomainEvent in events)
                {
                    await _mediator.Publish(entityDomainEvent);
                }
            }
        }
    }

5. Handle the Domain Event:

Implement a handler for your domain event. The handler should implement the INotificationHandler interface from MediatR.

    public class OrderPlacedEventHandler : INotificationHandler<OrderPlacedEvent>
    {
        public Task Handle(OrderPlacedEvent notification, CancellationToken cancellationToken)
        {
            // Handle the event (e.g., send an email notification)
            Console.WriteLine($"Order placed with ID: {notification.OrderId} on {notification.OrderDate}");
            return Task.CompletedTask;
        }
    }

6. Register Dependencies:

Finally, register MediatR and your handlers in the dependency injection container.

    public class Startup
    {
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddDbContext<AppDbContext>(options => 
                options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

            services.AddMediatR(typeof(Startup).Assembly);
            // Register other services and handlers
        }
    }

By following these steps, you can effectively implement domain events in your C# application using Entity Framework Core 8 and MediatR. This approach helps you maintain a clean separation of concerns, decouple your application's components, and improve testability.

Understanding Interceptors:
Interceptors serve as middleware within EF Core, enabling developers to intercept various stages of database operations. From creating and modifying entity instances to handling concurrency conflicts, interceptors provide flexibility and control over EF Core's behavior.

New and Enhanced Interceptors:
EF7 introduces several enhanced interceptors, allowing developers to:

1. Materialization Interception: Modify entity instances during creation, facilitating tasks such as setting unmapped properties or injecting services.

2. Query Expression Interception: Modify LINQ expression trees before compilation, ensuring stable ordering and enhancing query performance.

3. Concurrency Handling Interception: Provide mechanisms to handle optimistic concurrency conflicts, allowing graceful conflict resolution.

Practical Example: Suppressing Errors on Entity Deletion:
Consider a scenario where multiple requests attempt to delete the same entity simultaneously. In EF Core 7, we can use interceptors to suppress errors when deleting entities with no results, ensuring smooth application operation even in concurrent scenarios.

public class SuppressDeleteErrorInterceptor : ISaveChangesInterceptor
{
    public InterceptionResult<int> SavingChanges(DbContextEventData eventData, InterceptionResult<int> result)
    {
        var deletedEntries = eventData.Context.ChangeTracker.Entries()
            .Where(e => e.State == EntityState.Deleted && !e.Metadata.IsOwned());

        if (deletedEntries.Any())
        {
            var nonDeletedEntriesCount = eventData.Context.ChangeTracker.Entries()
                .Count(e => e.State != EntityState.Deleted && !e.Metadata.IsOwned());

            // Check if there are no non-deleted entries
            if (nonDeletedEntriesCount == 0)
            {
                Console.WriteLine("Suppressing deletion error for entity without results.");
                return InterceptionResult<int>.SuppressWithResult(0); // Suppress the deletion error
            }
        }

        return result;
    }
}

Considerations and Best Practices:
While interceptors offer significant flexibility, it's essential to use them judiciously and consider potential implications on application behavior. Ensure that interceptors align with application requirements and adhere to best practices to maintain code clarity and robustness.

Avoiding Database Operation Errors:
The SuppressDeleteErrorInterceptor introduced above effectively suppresses errors that may occur during entity deletion, such as the common error message: "Database operation expected to affect 1 row(s) but actually affected 0 row(s). Data may have been modified or deleted since entities were loaded." By implementing this interceptor, applications can gracefully handle scenarios where the expected deletion operation affects no rows, thus avoiding unnecessary error notifications.

Conclusion:
EF Core 7 interceptors provide powerful tools for customizing database interactions, enabling developers to address complex scenarios with ease. By leveraging interceptors effectively, developers can enhance application performance, maintain data integrity, and ensure smooth operation even in challenging concurrent scenarios.