Is Mediatr the right tool for my use case?

[rcdailey]

I have a .NET 8 console application. I need to integrate support for notifications in my application. Notifications in this case means using some third party service (Apprise) to publish important events that occur when users execute command line functionality.

The way I plan on implementing this so far is to have a NotificationEmitter class with several methods on it (e.g. NotifyError(), NotifyStatistic()). Each notification "type" is responsible for handling that event in its own way, which could be storing a string in a list, or incrementing a counter for metrics. Once the entire command line execution is completed, I have a NotificationService that should gather all metrics/strings/etc from each notification sent and build a single, large notification out of that data and publish the notification itself. This could be sent as an email, a discord notification, or something else (Apprise takes care of that for me).

Is Mediatr the right tool for this? My current approach is to use IObservable, but this requires me to essentially reimplement a lot of the patterns that Mediatr already implements. I want to give Mediatr a shot but I'm not sure if it's the way to go. If all of the event handlers are registered in DI as transient by default, it doesn't make sense to create potentially hundreds of notification handler instances within a command line program that completes execution in 10 seconds or less. I realize I could probably register the handlers as a singleton but that seems like an anti-pattern to me.

I'd love to hear from others about how Mediatr is a good fit here, and if not, maybe provide some architectural advice.

[ardalis]

Since you're trying to talk to another app, not just internal within your app, I'd take a look at MassTransit (or possibly NServiceBus if you have stricter requirements and need a commercial solution). MT is pretty easy to get going and should do what you need. See this super quick article I wrote recently on how to get it set up in under 5 minutes:
https://ardalis.com/introduction-to-masstransit-csharp-guide/

[rcdailey]

I apologize for the misunderstanding. The notification handlers would not be sending anything outside of my console app. The handlers themselves would store data in a list or increment a counter, but the process of gathering that information and sending it to a third party service would be done before my application exits, elsewhere and outside of events.

I only mentioned the third party app (Apprise) for context on what problem I'm solving. However the usage of Mediatr itself would only be to allow two objects in my code (same process) to communicate. And these notifications could be scattered across my code base wherever they're needed, which seems to be a good fit for this pattern.

[rcdailey]

@ardalis was my clarification helpful? I do not think MassTransit is the solution I need here.

[ardalis]

I think you could use MediatR for this, and at least see how it works for you. I don't see anything in your description that would make MediatR a bad fit. If performance or memory use are paramount, then there are other ways to implement MediatR-like behavior that might be more performant or efficient. But if these aren't a huge concern (usually they're not), then again, MediatR should be fine. Really, since it will probably take under 2 hours to try, I would try it and then see how you like the resulting patterns/code/organization. If you do, please report back!

[rcdailey]

Thank you @ardalis for the reassurance. I will certainly give this a shot and let you know how it goes. I wasn't able to find any guidance on how to deal with state in request handlers. Request handlers by default are transient, so I guess they're meant to be immutable. I could have them access a scoped/singleton service to store state into, but that seems to violate open/closed principle (i.e. I'd have to add new methods to a service class to handle new kinds of state, such as a counter or list of strings).

Is there any reading material you can point me to which will provide some design guidance for where to persist state across multiple requests?