ivanpaulovich/FluentMediator

FluentMediator is a .NET library that implements a loosely coupled mediator pattern with support for synchronous, asynchronous, and cancellable message handling. It utilizes a configurable pipeline architecture that allows users to define and route messages through distinct named or typed processing chains. The system integrates with Microsoft.Extensions.DependencyInjection to manage service lifetimes and includes validation logic to ensure pipeline configuration integrity.

A new AspNetCore sample has been added to the repository, demonstrating a customer registration feature built with ASP.NET Core. The sample includes a solution file, Visual Studio Code launch and task configurations, and a WebApi project that exposes a POST endpoint for registering customers. It implements a core domain model with a Register use case and an in-memory customer repository, wired together via dependency injection and the FluentMediator library for command handling. Unit tests are also included to verify the registration logic.

samples, samples/AspNetCore · high confidence

The FluentMediator integration with Microsoft.Extensions.DependencyInjection now offers explicit methods to register the mediator with different service lifetimes. In addition to the existing transient registration, users can now call AddScopedFluentMediator or AddSingletonFluentMediator to control the lifecycle of the pipeline provider and mediator instance, allowing for scoped or singleton behavior in their application architecture.

src/FluentMediator.Microsoft.Extensions.DependencyInjection · high confidence

This change introduces the initial version of the FluentMediator library, a loosely coupled mediator for .NET that supports async methods, cancellation tokens, and named pipelines. It includes the core library, a Microsoft.Extensions.DependencyInjection integration package, and unit tests. The repository is configured with Azure Pipelines to automatically build, test, and publish NuGet packages on tag creation, alongside standard project scaffolding like .editorconfig and contributor tracking.

(repo-wide) · high confidence

The library now supports named pipelines, allowing users to define and select specific processing chains by name rather than relying solely on type-based resolution. This change introduces a new builder API (\IPipelineBuilder\, \PipelineBuilder\) for constructing these pipelines, along with interfaces like \ISyncMediator\ and \ISyncPipelineProvider\ that expose \Send\ and \Publish\ methods accepting an optional \pipelineName\ parameter. The internal pipeline execution model has been refactored to support this, including a \Direct\ handler for return values and a \Pipeline\ class that manages method collections and named identity.

src/FluentMediator/Pipelines/Pipeline · high confidence

The pipeline system now supports named pipelines, allowing users to identify and retrieve pipelines by a unique string name in addition to the existing type-based lookup. This change introduces a new \INamedPipeline\ interface and updates the \PipelineCollection\ to maintain separate registries for typed and named pipelines. To ensure configuration integrity, the system now throws a \PipelineAlreadyExistsException\ if a duplicate name or type is registered, and a \PipelineNotFoundException\ if a requested pipeline cannot be found. Additionally, a \ReturnFunctionIsNullException\ is available to handle cases where a pipeline's return function is not defined.

src/FluentMediator/Pipelines · high confidence

The FluentMediator library has been refactored to use a pipeline architecture, allowing users to define and execute message handlers through configurable pipelines. This change introduces support for named pipelines, enabling users to route specific message types to distinct handler chains via an optional \pipelineName\ parameter on \Send\ and \Publish\ methods. The mediator now supports synchronous, asynchronous, and cancellable execution modes, each with its own pipeline provider and builder. Additionally, a \PipelineNotFound\ event is exposed to handle cases where a specified pipeline does not exist, and null request validation has been added to throw \NullRequestException\ when null messages are passed.

src/FluentMediator · high confidence

Added unit test infrastructure for PingPong handler; Added unit tests for mediator pipeline configuration and execution.

This change introduces a new AspNetCore sample application (located in samples/AspNetCore) demonstrating the library with .NET Core 3.0, alongside a SimpleConsoleApp sample. It also updates the main UnitTests project to use xUnit 2.4.1, Moq 4.13.1, and Microsoft.NET.Test.Sdk 16.4.0, while the AspNetCore UnitTests sample references Microsoft.Extensions.DependencyInjection 3.0.0.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 57 → 55 (-2.0)
• Rubric changed (rubric-2026.08.17 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 91 → 93 (+1.4)
• Architecture 98 → 98 (+0.0)
• Maturity 49 → 49 (+0.0)
• Readiness 55 → 57 (+1.8)
• Security 80 → 55 (-25.0)
• Performance 60 → 60 (+0.0)

• Ambiguous method overloading based on parameter type (Type vs string).
• Build did not complete in the analyzer
• Coverage not measured — analyzer environment
• Inconsistent parameter ordering and overloading strategy for synchronous vs asynchronous methods.
• Monorepo: only 1 of 3 solutions was scored
• Test reliability not measured — no test run produced results
• The Why section (the motivating problem) appears in the outline but is not present in the visible text. (README.md)
• dormant codebase — no living knowledge left to concentrate
• misleading comment (test/UnitTests/MyCustomMediator.cs)
• misleading comment (test/UnitTests/PublishingRequestsTests.cs)
• misleading comment (test/UnitTests/PublishingRequestsTests.cs)

• Conflicting pipeline registration APIs. On<TRequest>() returns a builder for a specific request type, while Add(...) takes a pre-constructed pipeline builder. It is unclear if these are mutually exclusive, complementary, or if On is just a convenience wrapper for Add. The naming On vs Add suggests different intents (event handling vs collection addition) but they likely serve the same domain purpose (registering behavior).
• Coverage not measured — broken report
• Documentation: no architecture or design documentation (README.md)
• End-of-life runtime: .NET netcoreapp2.2
• End-of-life runtime: .NET netcoreapp3.0
• Inconsistent naming convention for test methods. Some tests use the pattern Action_ExpectedOutcome (e.g., SendAsync_Returns_Response), while others use a verbose sentence structure describing the failure condition or specific scenario (e.g., SendAsync_Without_Return_Throws_ReturnFunctionIsNullException, Send_Throws_Exception_Null_Requests). The latter mixes the action, condition, and exception in a way that is not parallel to the standard Given_When_Then or Action_State conventions used in the majority of the other tests.
• Inconsistent naming for pipeline retrieval. The sync provider uses GetPipeline, the async provider uses GetAsyncPipeline, and the cancellable provider uses GetCancellablePipeline. This creates three different verbs for the same logical operation (retrieving a pipeline by type/name), increasing cognitive load.
• Inconsistent parameter ordering for async methods. The synchronous methods have pipelineName as the last parameter, but the async methods with CancellationToken have cancellationToken before pipelineName. This forces callers to use named arguments or remember different orderings for sync vs async.
• No SBOM
• No artifact signing
• No build provenance
• No dependency advisory monitoring
• redundant comment (test/UnitTests/MyCustomMediator.cs)
• redundant comment (test/UnitTests/PublishingRequestsTests.cs)

• Unchanged — 1 HTTP endpoints

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

ivanpaulovich/FluentMediator was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.