Allow NCronJob access to IConfiguration

[falvarez1]

Objective:

Enhance the configuration process of NCronJob by proposing two new methods to integrate IConfiguration access into the AddNCronJob method. This change aims to reduce boilerplate code, streamline the configuration process for developers, and lay the foundation for easily integrating future features that require configuration. By centralizing configuration access, we can more effectively manage and introduce new settings and features without disrupting the existing implementation or increasing the complexity for developers.

Proposed Enhancements

Method 1: Optional Parameter (Non-breaking Change)
Introduce an optional parameter to the existing AddNCronJob method that allows passing IConfiguration explicitly. This approach maintains compatibility with current usage while offering flexibility for developers who wish to manage their configuration more directly.

public static IServiceCollection AddNCronJob(this IServiceCollection services, Action<NCronJobOptionBuilder>? options = null, IConfiguration? configuration = null)
{
    var configuration = builder.Configuration;

    var concurrencySettings = new ConcurrencySettings();
    configuration.GetSection("NCronJob:Concurrency").Bind(concurrencySettings);

    ...

    return services;
}

// would be used like this:
builder.Services
        .AddNCronJob(n =>
            n.AddJob<PrintHelloWorldJob>(p =>
                p.WithCronExpression("*/2 * * * *"))
            , builder.Configuration);

Method 2: Extend WebApplicationBuilder (Breaking Change)
Propose a more integrated approach by making AddNCronJob an extension of WebApplicationBuilder. This method inherently accesses IConfiguration directly within the extension, simplifying the API and aligning with ASP.NET Core configuration practices.

public static WebApplicationBuilder AddNCronJob(this WebApplicationBuilder builder, Action<NCronJobOptions> configure)
{
    var services = builder.Services;
    var configuration = builder.Configuration;

    ...

    return builder;
}


// would be used like this:
builder.AddNCronJob(n =>
        n.AddJob<PrintHelloWorldJob>(p =>
            p.WithCronExpression("*/2 * * * *"))
    );

[linkdotnet]

My current way of thinking was that the user should be responsible for all configuration and just pass down the values to us that are necessary. While I do see an appeal for the second approach (which I would prefer) I am still not totally convinced that we should push this right now.

@falvarez1, can you elaborate on where this either makes our current code much simpler or allows (right now) new scenarios?
Don't get me wrong - we can think of this for v3 or vNext, but I am not 100% convinced.

[falvarez1]

This is mostly for paving the way to future enhancements. For example the dashboard component needs a way to provide a URI and some type of secret or access token. This would differ based on environment and infrastructure, you would want devs to have access to make changes in real-time without recompiling. Sure the developers could create their own way to push configuration into the extension methods but I think the dev experience starts to suffer.
Another example would be to disable a particular job or updating the schedule just by updating a configuration. If this is used to create a Job Host that runs many jobs, it's not convenient to restart the service, potentially cancelling running jobs, just to make an adjustment to a Cron expression or to disable/enable a Job.

Regarding simplifying code, it wouldn't necessarily simplify the internal library code but the second option would just reduce boilerplate anywhere we would need access to IConfiguration.

[linkdotnet]

Really good thoughts and I do agree - for the time being I will flag this as „Future“.

[linkdotnet]

I moved this to v3 as we might have to introduce a breaking change here.
Of course we could pass in a IConfiguration? config but that seems rather dirty.

[linkdotnet]

Potential first candate: MaxDegreeOfParallelism

[falvarez1]

@linkdotnet I've update your branch for global-configurable 4fc5ae0

This should handle the scenario where calling the Services.NCronJob() multiple times affects the settings that are used in the Job's concurrency. This works with both providing the Action<GlobalOptions> either in the first call or any other call. This also works with IConfiguration.

If AddNCronJob is called on the WebApplicationBuilder then it will check if there's a record in the appsettings. The order is:

1. The configuration values from appsettings.json are bound to GlobalOptions.
2. Any additional configuration provided through the configureGlobalOptions parameter can override these values.

If 'AddNCronJob' is called from the IServiceCollection then everything works as it does today. If configureGlobalOptions is passed then this will override any defaults.