Stratara.Validation
3.1.3
dotnet add package Stratara.Validation --version 3.1.3
NuGet\Install-Package Stratara.Validation -Version 3.1.3
<PackageReference Include="Stratara.Validation" Version="3.1.3" />
<PackageVersion Include="Stratara.Validation" Version="3.1.3" />
<PackageReference Include="Stratara.Validation" />
paket add Stratara.Validation --version 3.1.3
#r "nuget: Stratara.Validation, 3.1.3"
#:package Stratara.Validation@3.1.3
#addin nuget:?package=Stratara.Validation&version=3.1.3
#tool nuget:?package=Stratara.Validation&version=3.1.3
Stratara.Validation
License: FSL-1.1-MIT (Functional Source License — source-available; converts to MIT after 2 years). Not OSI-approved OSS.
Vendor-neutral request validation for Stratara's CQRS pipeline. A mediator pipeline behavior
runs your IValidator<T> implementations before the handler and throws an aggregated
StrataraValidationException when validation fails — no third-party validation dependency in
the default path.
Quick start
// 1. Register the behavior (outermost) + discover validators.
builder.Services
.AddStrataraValidation()
.AddValidatorsFromAssemblyContaining<IAppMarker>();
// 2. Write a validator (the contracts live in Stratara.Abstractions.Validation).
public sealed class CreateOrderValidator : IValidator<CreateOrder>
{
public ValueTask<ValidationResult> ValidateAsync(CreateOrder cmd, CancellationToken ct = default)
=> ValueTask.FromResult(string.IsNullOrWhiteSpace(cmd.CustomerId)
? new ValidationResult([new ValidationFailure(nameof(cmd.CustomerId), "Customer is required.")])
: ValidationResult.Success);
}
// 3. Catch the failure in your global handler and map it to your error model.
catch (StrataraValidationException ex)
{
// ex.Failures -> RFC-7807 ProblemDetails 400, your error codes, etc.
}
How it works
AddStrataraValidation()registersIPipelineBehaviorfor both request shapes (IRequestandIRequest<TResult>). Register it before other behaviors so validation runs outermost — before authorization, auditing, and the handler.- All validators for a request run; their failures are aggregated.
- Severity policy: only
ValidationSeverity.Errorblocks (throwsStrataraValidationException).WarningandInfofailures pass through and are logged.
Contracts
The validation contracts (IValidator<T>, ValidationResult, ValidationFailure,
ValidationSeverity, StrataraValidationException) live in Stratara.Abstractions
(namespace Stratara.Abstractions.Validation) so consumers can implement validators and catch
the exception without referencing this behavior package.
The contract shape is FluentValidation-compatible; an optional
Stratara.Validation.FluentValidation adapter can be shipped to plug FluentValidation
validators into the same pipeline.
Dependencies
Stratara.AbstractionsStratara.MediatorStratara.DiagnosticsMicrosoft.Extensions.DependencyInjection.AbstractionsMicrosoft.Extensions.Logging.Abstractions
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net10.0 is compatible. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
-
net10.0
- JetBrains.Annotations (>= 2025.2.4)
- Microsoft.Extensions.DependencyInjection.Abstractions (>= 10.0.8)
- Microsoft.Extensions.Logging.Abstractions (>= 10.0.8)
- Stratara.Abstractions (>= 3.1.3)
- Stratara.Diagnostics (>= 3.1.3)
- Stratara.Mediator (>= 3.1.3)
NuGet packages
This package is not used by any NuGet packages.
GitHub repositories
This package is not used by any popular GitHub repositories.
### Added
- **Mediator tenant-isolation behavior** (`Stratara.Mediator`) — `AddStrataraTenantIsolation()`
registers a pipeline behavior that enforces tenant isolation at the mediator entrance, before the
handler runs, for any request that opts in via the new `ITenantScopedRequest` marker
(`Stratara.Abstractions.Multitenancy`). The behavior compares the request's `TenantId` (data owner)
against the ambient session's data-owner tenant and rejects a mismatch with the new
`TenantAccessDeniedException` (translated to HTTP 403 on ASP.NET hosts). `TenantIsolationMode.Default`
enforces only the subject match (privileged cross-tenant operations pass when the endpoint promoted
the session subject to the target); `TenantIsolationMode.Strict` additionally routes every
cross-tenant operation through the new `ICrossTenantAuthorizer`, whose shipped default denies all
cross-tenant access until a consumer registers its own authorizer. Complements the existing
database-side `ApplyGlobalTenantQueryFilters` with a command-/query-entrance guard. New log-event
IDs `114_101`/`114_102`/`114_003` in `Stratara.Diagnostics`.
- **`Stratara.Abstractions.Persistence.ConcurrencyConflictException`** — provider-agnostic
wrapper for an optimistic-concurrency conflict detected during commit. Allows framework-level
code in `Stratara.Projections` (and any consumer outside the `EntityFrameworkCore` package) to
react to concurrency without taking an EF Core dependency. EF Core's `DbUpdateConcurrencyException`
(and provider equivalents) flow through this type.
### Changed
- **`EfTransaction.SaveChangesAsync`** (in `Stratara.EventSourcing.EntityFrameworkCore`) now
wraps `DbUpdateConcurrencyException` thrown by EF Core in the new
`ConcurrencyConflictException`. PostgreSQL unique-violation paths remain on `DbUpdateException`
(different semantics — duplicate-key on insert vs. stale-row on update/delete).
- **`EventSource.SaveChangesAsync`** (write-side append flow) extends its concurrency-handling
catch to the new exception type so the existing append-conflict recovery path keeps working
after the wrap. Behaviour for both EF concurrency conflicts and PostgreSQL unique violations
is unchanged.
### Fixed
- **`TenantProjection` no longer aborts the event bundle on a parallel delete race.** The two
delete handlers (`TenantDeleted`, `CustomerTenantsDeleted`) now swallow
`ConcurrencyConflictException` silently — a missing row is the desired end-state of a delete.
Before this fix, a consumer-side customer-delete cascade saga that emits both
`CustomerTenantsDeleted` and a follow-up `TenantDeleted` for the same tenants would race the
two parallel projection bundles on the same `TenantView` row; the loser threw
`DbUpdateConcurrencyException` out of `SaveChangesAsync`, which propagated through
`ProjectionWorker` and caused `RabbitMqBus` to roll back the entire bundle — including
sibling projections that had already committed. Update handlers (rename / activate /
deactivate / locale / customer-assigned) keep their current behaviour: a concurrency failure
there is a real race that propagates.