Table of Contents

Integration

When you adopt Trellis, the hard part is rarely Result<T> itself. The real work is making it feel natural in HTTP APIs, validation, persistence, authorization, and observability. These guides show the pieces that fit around Trellis in real applications.

Patterns Index

Goal Article Topics
Map Result<T> to HTTP responses (MVC, Minimal APIs, Problem Details, ETags, Prefer) ASP.NET Core asp, http, problem-details
Authorize HTTP requests with actor-based claims ASP.NET Authorization asp, authorization, actor
Call HTTP APIs and bridge responses into Result<T> / Maybe<T> HTTP Client http, httpclient, json
Add validator-based input checks at the application boundary FluentValidation validation, fluentvalidation
Persist aggregates with EF Core and explicit failure mapping Entity Framework Core ef, persistence, repository
Apply pipeline behaviors (validation, logging, transactions) around handlers Mediator mediator, pipeline
Configure least-privilege database permissions Database Permissions ef, security, permissions
Sign users in via external identity providers SSO sso, authentication
Test against Microsoft Entra in integration tests Entra Testing testing, entra, sso
Write integration tests for Trellis-based services Testing testing, integration
Trace, correlate, and diagnose production behavior Observability observability, opentelemetry, tracing
Tip

If you are building a web API, start with ASP.NET Core Integration. It gives you the cleanest end-to-end path from domain results to HTTP responses.

Pick the guide you need

Guide Use it when you need to... What you will learn
ASP.NET Core Integration Turn Result<T> into clean HTTP responses MVC, Minimal APIs, Problem Details, ETags, Prefer, pagination
HTTP Client Integration Consume HTTP APIs without exception-driven control flow Functional status handling, deserialization into Result<T> and Maybe<T>
FluentValidation Integration Add richer validation rules at the application boundary Validator composition, async validation, converting failures to Trellis results
Entity Framework Core Integration Keep persistence explicit and result-driven Repository patterns, database exception mapping, pagination
Observability & Monitoring Trace and diagnose production behavior OpenTelemetry, correlation, break-glass Result tracing

How the pieces fit together

flowchart LR
    Client[Client Request]
    Asp[ASP.NET Core + Trellis.Asp]
    App[Application Layer]
    Domain[Domain Model]
    Infra[Infrastructure]

    Client --> Asp
    Asp --> App
    App --> Domain
    App --> Infra
    Domain --> App
    Infra --> App
    App --> Asp
    Asp --> Client

In practice, most Trellis applications follow the same flow:

  1. Validate input early with scalar-value validation and/or FluentValidation.
  2. Keep Result<T> inside your application layer while business rules run.
  3. Map results once at the boundary using ASP.NET Core or HttpClient integrations.
  4. Attach operational concerns like authorization, concurrency, persistence, and telemetry around that core flow.

A sensible learning path

If you are building an HTTP API

  1. Start with ASP.NET Core Integration
  2. Add FluentValidation Integration for business rules
  3. Add Entity Framework Core Integration for persistence
  4. Add ASP.NET Core Authorization if requests need actor-based authorization
  5. Finish with Observability & Monitoring

If you are calling other APIs

Start with HTTP Client Integration, then add the validation and observability guides as needed.

What stays the same across all guides

No matter which integration you use, the same design rule keeps paying off:

Note

Let Trellis types describe success and failure inside your application. Convert them to framework-specific responses only at the edge.

That usually means:

  • Result<T> stays in handlers, services, and repositories
  • ASP.NET Core controllers/endpoints call ToHttpResponse(...), with .AsActionResult<T>() for typed MVC signatures
  • outbound HTTP code turns responses back into Result<T>
  • validation, authorization, and persistence all return explicit failures instead of throwing for expected conditions

Quick start

If you want the shortest path to something useful:

using Trellis.Asp;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddTrellisAsp();

var app = builder.Build();
app.MapControllers();
app.Run();

From there:

  • add AddScalarValueValidation() when you use scalar value objects in requests
  • add integration-asp-authorization.md when HTTP claims need to become an Actor
  • add EF Core and FluentValidation integrations as your app grows

Next step

Go to ASP.NET Core Integration.

Cross-references

Edit this page