https://github.com/shuttle/shuttle.core.mediator
Implementation of the mediator mechanism.
https://github.com/shuttle/shuttle.core.mediator
Last synced: 4 months ago
JSON representation
Implementation of the mediator mechanism.
- Host: GitHub
- URL: https://github.com/shuttle/shuttle.core.mediator
- Owner: Shuttle
- License: bsd-3-clause
- Created: 2019-06-05T11:58:19.000Z (almost 7 years ago)
- Default Branch: master
- Last Pushed: 2025-03-02T14:03:37.000Z (about 1 year ago)
- Last Synced: 2025-06-06T03:04:55.239Z (9 months ago)
- Language: C#
- Size: 162 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Shuttle.Core.Mediator
```
PM> Install-Package Shuttle.Core.Mediator
```
The Shuttle.Core.Mediator package provides a [mediator pattern](https://en.wikipedia.org/wiki/Mediator_pattern) implementation.
## Configuration
In order to get all the relevant bits working you would need to register the `IMediator` dependency along with all the relevant `IParticipant` dependencies.
You can register the mediator using `IServiceCollection`:
```c#
services.AddMediator(builder =>
{
builder.AddParticipants(assembly);
builder.AddParticipant();
builder.AddParticipant(participantType);
builder.AddParticipant(participant);
builder.AddParticipant(async (IParticipantContext context) =>
{
await Task.CompletedTask.ConfigureAwait(false);
});
```
## IMediator
The core interface is the `IMediator` interface and the default implementation provided is the `Mediator` class.
Participants types are instatiated from the `IServiceProvider` instance. This means that it depends on how you register the type as to the behaviour.
```c#
Task SendAsync(object message, CancellationToken cancellationToken = default);
```
The `SendAsync` method will find all participants that implement the `IParticipant` with the type `T` of the message type that you are sending.
## Participant implementations
```c#
public interface IParticipant
{
Task ProcessMessageAsync(IParticipantContext context);
}
```
A participant would handle the message that is sent using the mediator. There may be any number of participants that process the message.
## Design philosophy
There are no *request/response* semantics and the design philosophy here is that the message encapsulates the state that is passed along in a *pipes & filters* approach.
However, you may wish to make use of one of the existing utility classes:-
### RequestMessage\
The only expectation from a `RequestMessage` instance is either a success or failure (along with the failure message).
### RequestResponseMessage\
The `RequestResponseMessage` takes an initial `TRequest` object and after the mediator processing would expect that there be a `TResponse` provided using the `.WithResponse(TResponse)` method. The same success/failure mechanism used in the `RequestMessage` class is also available on this class.
## Considerations
If you have a rather predictable sequential workflow and you require something with faster execution then you may wish to consider the [Shuttle.Core.Pipelines](http://shuttle.github.io/shuttle-core/shuttle-core-pipelines) package.
Performing a benchmark for your use-case would be able to indicate the more suitable option.