API Design: make strongly typed settings easier about options

[davidfowl]

Why do you want to use IOptions in the first place? Are are you saying that you want something else for pocos other than just putting instances in the container?

[jods4]

@davidfowl I don't want to use IOptions! But I got the impression from the docs that it was the suggested way.
There are good points, though.
Once you do app.Configure<AppSettings>(Configuration.GetSection("AppSettings")), you're ready to go:

1. The settings are taken from the configuration system (any source you have configured)
2. They are parsed into a strongly typed class for you
3. They are accessible pretty much anywhere with the DI.

I guess I would just like to be able to DI AppSettings directly, rather than IOptions<AppSettings>, which does not make a whole lot of sense (in this context at least).

Do you suggest another way?
Previously in ASP.NET, the "way" to do that was a designer in Properties that generated a strongly typed singleton class (usually MyNamespace.Properties.Settings).

[lodejard]

You're not required to use IOptions if you want to bind an object from config directly... You might need to add dependency on "Microsoft.Framework.Configuration.Binder": "1.0.0-*". For example:

    public class Startup
    {
        private readonly IConfiguration Configuration;

        public Startup(IApplicationEnvironment env)
        {
            Configuration = new ConfigurationBuilder(env.ApplicationBasePath)
                .AddJsonFile("config.json")
                .Build();
        }

        public void ConfigureServices(IServiceCollection services)
        {
            var settings = new MyNamespace.Properties.Settings();
            Configuration.GetSection("appSettings").Bind(settings);
            services.AddInstance(settings);
        }

Is that closer to the code you're prefer to have? The settings class can be used as a service or controller dependency directly at that point.

[divega]

FWIW, this terser syntax should already work with nightly builds:

    var settings = Configuration.Get<MyNamespace.Properties.Settings>("appSettings");

[jods4]

@lodejard yes, that would do the trick.
@divega and the new typed Gets (very good addition BTW) make it a lot cleaner!

Yet I somehow still believe the method that does those two (or three) lines of code should be in the framework. Maybe services.AddSettings<AppSettings>("appSettings").
Or just services.AddSettings<AppSettings>() and the section name might be in an attribute.

First because application settings is a fundamental thing. Every serious applications needs it. The framework should provide guidance on how to handle them, in an easily discoverable way.

Second, right now the helper method is trivial, that's true. But in the future you might want to include more features:

• transparent encryption (ok that would probably entirely be at the Configuration level?)
• save changes (by modifying Settings class directly, not through Configuration)
• live reload (because of thread safety you can't modify the Settings object directly, but you could replace the one in the DI for new services, and if it implements an ISettingsChanged interface or something, you could call a notification event so that part of the code that already have the settings may get the new ones).
• decide to merge app-wide settings and user-wide settings (that was in .NET of old times). It's not useful for ASP.NET, but if we start using .NET Core to build cross-platform console applications (or even x-plat UI) then it's needed.

Overall there is a lot of overlap between Configuration and what I call Settings, so maybe the former should be used for that latter. But currently it's a bit complicated for that.

[davidfowl]

@jods4 Seems like your initial problem is solved. If you want to have a more general discussion about configuration or request specific features, I'd suggest opening individual issues.

[jods4]

@davidfowl I opened this issue specifically to request simpler API for handling application settings.

I don't have a problem per se as everything works, so if you don't want to pursue this suggestion further feel free to close the issue.

[davidfowl]

Great!