Greetings masstransit-discuss!
I'm working on a new windows service and I need some best practice advice. The service's job is to periodically scan a directory full of files, move them, and then submit a message to the queue for a consumer to process each individual file. (One message per file)
There will be multiple producers and multiple consumers, though, the consumers will compete for messages rather than receive them all. The producers will be distributed but only one will be allowed to run at any given time.
The IJob instances need to know about the bus or at least something which allows it to publish a message.
I thought about having the IJob create its own instance of the IBusControl, but I don't think that is recommended. (Also its not unit testable)
I thought about creating a sort of BusRepo and using a DI container to send a singleton instance into the job but not sure if that's the right way to go either.
The other solution I came up with involves sending a callback (Action<T>) down into a custom IJobFactory in the Quartz job scheduler, and just pushing the callback around till it reaches the IJob. It keeps things 'testable' since an Action<T> is sort of loosely coupled, and it keeps to a single instance of an IBusControl, but I'm hesitant on this mostly because I don't want to write activator calls or hard-code any specific IJob types. That feels like something a DI container should be doing, but I don't know how MT would take to being injected by a container.
Mostly what I'm wondering about is whats the best practice for dealing with IBusControl instances in an environment like this?