Non-singleton instances about easy.messagehub

[NimaAra]

This is now possible as of v5.0.0

[srowan]

I think a non singleton implementation is critical in many scenarios including unit testing (tests running in parallel), background job processing, and most architectures that support any kind of "scoped" dependency trees. And I think all you'd have to do is make the constructor public? :)

And of course, agree with codeConcussion - great library otherwise!

[NimaAra]

The singleton instance is by design.

You should be able to achieve what you want by defining a base class UserMessage or IUserMessage from which you inherit other messages. Then those concerned with user scoped messages can publish/subscribe using the base class and receive all user related messages.

[NimaAra]

I have not heard from you so I am going to close this for now. Let me know how you get on.

[codeConcussion]

Not the original author, but I just ran into this need as well. Maybe you'll have a suggestion.

We're using Hangfire in our application to handle background processing on the server. It executes tasks concurrently on a configurable amount of threads. We'd like to implement pub/sub in this scenario using Hangfire and Easy.MessageHub.

To do that, a task gets queued in Hangfire that contains the message that needs published. When it executes, it looks at the message, instantiates all the interested subscriber classes (who subscribe in their constructor), then publishes the message. I'm running into a problem if multiple messages of the same type come in at the same time. Subscribers from other Hangfire threads are receiving messages they "shouldn't".

I think I could easily solve the issue if I could register an IMessageHub as Scoped instead of as a Singleton. Any thought or suggestions?

And on another note, this is a great little Event Aggregator library. So minimal and clean, I love it!

[NimaAra]

Can you not define your scoping logic as part of the event you are publishing? In other words, at the time of publishing and setting up the subscribers, define your scoping logic (however you see fit) and make it part of the message. The first thing your subscribers do would be checking that logic as part of the event they are receiving and ignore them if out of their scope.

Once again the design decision to make this library a singleton was a conscious one and I have no plans to change that.

[codeConcussion]

Thanks for the response. Yes, that's one way I could solve it. It just seems like a code smell for all messages and all subscribers to have to deal with the publisher's scope. Ideally, a subscriber should just handle a message it receives and not have to worry about where it came from. And to a lesser extent, a message should contain message-related data and not have to concern itself with who is sending it.

From my viewpoint, I don't see how letting consumers of the library decide how many MessageHubs to instantiate compromises the design of the library. True, most users would probably use the Singleton instance, but I don't see how allowing other use cases is a bad thing. No offense intended, just my opinion.

Once again, thanks for this great library!

[ryanbuening]

@srowan do you have an example of how you used this in a Blazor Server app? Do you need to handle disposing to prevent memory leaks?