Mediator is a behavioral design pattern that lets you reduce chaotic dependencies between objects. The pattern restricts direct communications between the objects and forces them to collaborate only via a mediator object.
Shiny Mediator is a mediator pattern implementation, but for built with ALL .NET apps in mind. We provide a TON of middleware out-of-box to get you up and rolling with
hardly any effort whatsoever. Checkout our Getting Started guide to see how easy it is. Imagine using 1 line of code to add offline, caching, or validation to your code!
This project is heavily inspired by MediatR with some lesser features that we feel
were aimed more at server scenarios, while also adding some features we feel benefit apps
We are AOT/Trim friendly in all aspects of how you use Mediator. We use source generators for almost everything (attribute registration, JSON serialization, dependency injection registration, & more)
Integrations allow your viewmodels or pages to implement an IEventHandler interface(s) without them having to participate in the dependency injection provider
Middleware built for apps including caching, offline support, & more
We still have a "messagingcenter" type subscribe off IMediator for cases where you can't have your current type implement an interface
Save the Boilerplate + Receive the Power of Middleware
MVVM Frameworks like Prism, ReactiveUI, & .NET MAUI Shell
Blazor - Work In Progress
Any other .NET platform - but you'll have to come up with your own "event collector" for the out-of-state stuff
What Does It Solve
Problem #1 - Service & Reference Hell
Does this look familiar to you? Look at all of those injections! As your app grows, the list will only grow. I feel sorry for the dude that gets to unit test this bad boy.
With a bit of our middleware and some events, you can get here:
public partial class MyViewModel(IMediator mediator) : IEventHandler<ConnectivityChangedEvent>, IEventHandler<AuthChangedEvent> {
// ...
var myData = await mediator.Request(new GetDataRequest());
// logging, exception handling, offline caching can all be bundle into one nice clean call without the need for coupling
}
public partial class GetDataRequestHandler : IRequestHandler<GetDataRequest, MyData> {
[OfflineAvailable] // <= boom done
public async Task<MyData> Handle(GetDataRequest request, CancellationToken cancellationToken) {
// ...
}
}
Problem #2 - Messages EVERYWHERE (+ Leaks)
Do you use the MessagingCenter in Xamarin.Forms? It's a great tool, but it can lead to some memory leaks if you're not careful. It also doesn't have
a pipeline, so any errors in any of the responders will crash the entire chain. It doesn't have a request/response style setup (not that it was meant for it), but
this means you still require other services.
public class MyViewModel
{
public MyViewModel()
{
MessagingCenter.Subscribe<SomeEvent1>(this, @event => {
// do something
});
MessagingCenter.Subscribe<SomeEvent2>(this, @event => {
// do something
});
MessagingCenter.Send(new SomeEvent1());
MessagingCenter.Send(new SomeEvent2());
// and don't forget to unsubscribe
MessagingCenter.Unsubscribe<SomeEvent1>(this);
MessagingCenter.Unsubscribe<SomeEvent2>(this);
}
}
Let's take a look at our mediator in action for this scenarios
public class MyViewModel : IEventHandler<SomeEvent1>, IEventHandler<SomeEvent2>
{
public MyViewModel(IMediator mediator)
{
// no need to unsubscribe
mediator.Publish(new SomeEvent1());
mediator.Publish(new SomeEvent2());
}
}
Problem #3 - Strongly Typed Navigation with Strongly Typed Arguments
Our amazing friends over in Prism offer the "best in class" MVVM framework. We'll them upsell you beyond that, but one
of their amazing features is 'Modules'. Modules help break up your navigation registration, services, etc.
What they don't solve is providing a strongly typed nature for this stuff (not their job though). We think we can help
addon to their beautiful solution.
A normal call to a navigation service might look like this:
_navigationService.NavigateAsync("MyPage", new NavigationParameters { { "MyArg", "MyValue" } });
This is great. It works, but I don't know the type OR argument requirements of "MyPage" without going to look it up. In a small project
with a small dev team, this is fine. In a large project with a large dev team, this can be difficult.
Through our Shiny.Framework library we offer a GlobalNavigationService that can be used to navigate to any page in your app from anywhere, however,
for the nature of this example, we'll pass our navigation service FROM our viewmodel through the mediator request to ensure proper scope.
public record MyPageNavigatonRequest(INavigationService navigator, string MyArg) : IRequest;
public class MyPageNavigationHandler : IRequestHandler<MyPageNavigatonRequest>
{
public async Task Handle(MyPageNavigatonRequest request, CancellationToken cancellationToken)
{
await request.navigator.NavigateAsync("MyPage", new NavigationParameters { { "MyArg", request.MyArg } });
}
}
Now, in your viewmodel, you can do this:
public class MyViewModel
{
public MyViewModel(IMediator mediator)
{
mediator.Request(new MyPageNavigationCommand(_navigationService, "MyValue"));
}
}
Strongly typed. No page required page knowledge from the module upfront. The other dev team of the module can define HOW things work.