Feature Request: Allow the job configuration (registration) surfaces to support all of / the same options otherwise handled by class or method level Attributes

[bhehe]

trafficstars

I'm leveraging Hangfire in a new project and one of the things I've bumped into is that some of the configuration & behavioral traits are only supported by use of an Attribute. In my case I'm primarily working with Recurring Jobs and their registrations.

I.e. I can express the Queue name via Attribute -or- as part of the Recurring Job registration. But other traits/behaviors like the [DisableConcurrentExecution] attribute offers cannot be done via configuration. This means that any changes require a rebuild/redeploy of the code - i.e. changing the timeout.

While the attributes seem like they should be there for convenience, I would have expected they would also have their parallels in the recurring job registration itself. I'm not familiar with the Hangfire internals enough to weigh in on it, but it would seem like those are something that could be expressed on that same job registration/configuration surface.

Another scenario I've bumped into where this was problematic is that another engineer has implemented MediatR at the Job level which he used a 'Job Adapter' paradigm and now the main code entry point - as far as Hangfire's perspective - is this adapter's Type and it's "Send" method. This means any class-level/method-level decorations would have to apply to all cases and wouldn't be able to vary / be configured for each job implementation. The adapter is generic, and the 'commands' equate to the discrete jobs.

Aside from whether that was a good design choice or not, if these configuration & behavioral traits could have been expressed by the job registration instead of by Attributes I would have had a viable path to work around that scenario.

[bhehe]

A related feature request was submitted that would ideally support what is being asked for here.

https://github.com/HangfireIO/Hangfire/issues/2019