Equivalent to fubu's Setting model

[jeremydmiller]

I think this is going to be much simpler in Core's much better configuration model, but still.

Personally, I think that the way ASP.Net Core uses its IOptions mechanism is bonkers and unnecessarily clumsy. Admittedly, their configuration design is based on the idea that configuration is variable during the lifetime of the application. If we forgo that capability, I think our usage could be much simpler.

The goal of this story is to provide strong typed configuration much the same way we did in FubuMVC. We'd surely want to also support the IOptions<T> pattern that ASP.Net Core supports. The basic idea is that at application bootstrapping time you hydrate all the Settings Type's known upfront and each is registered in the StructureMap container as a singleton. In addition, if a previously unknown Settings type is requested at runtime, we should have a StructureMap policy (like this one from FubuMVC)

Using fubu as a guide, we should support a combination of loading configuration objects from:

• The ASP.Net Core Configuration infrastructure -- but there is an open question about whether that will all be from trying to deserialize a matching configuration section or if we bind key/value
  pairs like we did in FubuMVC. For the sake of environment variables, I'd guess the answer is "both".
• If there is no matching configuration found, just new up requested Settings
• Directly injected or "replaced" objects built into the IoC container
• Applying user specified alteration lambda's registered in the JasperRegistry

[jeremydmiller]

https://fubumvc.github.io/documentation/basics/settings/

[jeremydmiller]

To add a little more context to this one, here are the potential use cases inside the JasperRegistry configuration for an application

public class MyApp : JasperRegistry
{
    public MyApp()
    {
        // Applies changes to the previously loaded MySettings object
        Settings.Alter<MySettings>(_ => {
            _.Property1 = "something";
            _.Property2 = "else";
        }

        // Completely replace any previous settings
        Settings.Replace(new MySettings{ });

        // This is new for Jasper, would have cleaned up some usage
        // in FubuMVC. This is using the loaded configuration of a Settings object
        // to configure the JasperRegistry itself
        Settings.With<MySettings>(_ => {
            if (_.Mode == "some mode")
            {
                // change the configuration of the application
            }

        }

    }
}

At bootstrapping time, the first step is to create your JasperRegistry object. When the Settings.Replace() or Settings.Alter() or Settings.With() methods are called, let's just stash the Lambda's for later execution because it's very important to do things in the right order so that coded alterations are applied.

[jeremydmiller]

@mwuthrich A few comments I jotted down yesterday:

• LATER - we might/probably want to abstract the initial loading mechanism a little bit for other approaches.
• Some kind of key/value source abstraction that we could use to bind data to the Settings objects. Environment variables being the first thing I can think of
• The Configure<T>() method w/ no arguments. We might want to rename that to something that says "load me upfront." In fubu, you could happily delay the loading of Settings objects to runtime whenever they're needed for the first time, so you wouldn't necessarily have to tell Jasper about it upfront. Always some tension between "it should just work" and making things explicit
• Do we need to "namespace" the key/value pairs or JSON sections the way we did in fubu w/ "[class name].[prop/field/accessor]"? Just thinking that it'd be pretty common to have multiple Settings classes with the same named properties. Or at least possible anyway.
• Possibly think about how we could or could not parallelize the Settings loading, alterations, and maybe even the With() calls -- but let's wait until bootstrapping time is a problem. Might not be an issue at all.

[jeremydmiller]

@mwuthrich I want to call this one closed if that's alright with you. I'd rather just open smaller, focused issues on whatever else we come up with against this.