What is Separation of Concerns, and how does it show up in an ASP.NET Core application?

1. Origin

Edsger Dijkstra (1974, On the role of scientific thought) described focusing on one aspect of a problem at a time, "the separation of concerns", as the only effective technique for ordering thoughts. David Parnas' information hiding (1972) is the modular-design counterpart: hide each design decision likely to change behind a module boundary.

2. Scales of separation

3. The ASP.NET Core pipeline as a SoC tool

Request → [Exception handler] → [HTTPS/HSTS] → [Routing] → [CORS] → [Authentication] → [Authorization]
        → [Rate limiting] → [Output cache] → Endpoint filters → Endpoint (HTTP concern only) → Service (rules) → DbContext (persistence)

Each concern sits at one place in the pipeline. Order matters (authentication before authorisation; exception handling first so it wraps everything).

4. Cross-cutting concerns for services (beyond HTTP)

// Decorator for timing/logging around any IQuoteService
public sealed class LoggingQuoteService(IQuoteService inner, ILogger<LoggingQuoteService> log) : IQuoteService
{
    public decimal ShippingQuote(string postcode)
    {
        var sw = Stopwatch.StartNew();
        try { return inner.ShippingQuote(postcode); }
        finally { log.LogInformation("Quote for {Postcode} took {Ms} ms", postcode, sw.ElapsedMilliseconds); }
    }
}

Other tools: MediatR-style pipeline behaviours, EF Core interceptors (auditing, soft delete), HttpClient delegating handlers (auth headers, resilience).

5. Presentation vs logic

Razor views and Blazor components should render and handle UI events; calculations and rules belong in injectable services that can be unit-tested without a UI. Blazor's @code blocks are a common place for logic to creep in.

6. Signs you've gone too far

• Adding a field touches 6+ files with no added behaviour.
• Layers that only map one object to an identical one.
• Developers can't find where a behaviour lives.
• Every feature needs a command, handler, validator, mapper, DTO and response class even when trivial.

Remedies: vertical slices, merging pass-through layers, mapping only at real boundaries (API contract ↔ domain).

7. Try it yourself

1. Pick a controller action and list every concern inside it.
2. Move error handling into IExceptionHandler and validation into an endpoint filter (as in the code example).
3. Add a fallback authorisation policy and confirm endpoints are protected by default.
4. Count lines left in the action and in its tests.
5. Reorganise one feature into a vertical slice and compare a typical change's diff size.

using Microsoft.AspNetCore.Diagnostics;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddProblemDetails();
builder.Services.AddExceptionHandler<DomainExceptionHandler>(); // error concern
builder.Services.AddSingleton<QuoteService>();                  // business concern
var app = builder.Build();

app.UseExceptionHandler();

// HTTP concern only: bind, call, map to a result.
app.MapGet("/quotes/{postcode}", (string postcode, QuoteService quotes) =>
        Results.Ok(quotes.ShippingQuote(postcode)))
   .AddEndpointFilter(async (ctx, next) =>              // validation concern
   {
       var postcode = ctx.GetArgument<string>(0);
       return postcode.Length == 4 && postcode.All(char.IsDigit)
           ? await next(ctx)
           : Results.ValidationProblem(new Dictionary<string, string[]> { ["postcode"] = ["Must be 4 digits"] });
   });

app.Run();

public sealed class QuoteService
{
    public decimal ShippingQuote(string postcode) =>
        postcode.StartsWith('6') ? 19.95m : postcode == "0000" ? throw new DomainException("No delivery") : 9.95m;
}

public sealed class DomainException(string message) : Exception(message);

public sealed class DomainExceptionHandler(IProblemDetailsService problems) : IExceptionHandler
{
    public async ValueTask<bool> TryHandleAsync(HttpContext http, Exception ex, CancellationToken ct)
    {
        if (ex is not DomainException) return false;
        http.Response.StatusCode = StatusCodes.Status422UnprocessableEntity;
        return await problems.TryWriteAsync(new() { HttpContext = http, Exception = ex });
    }
}