IT:AD:Patterns:App Settings != Host Settings != User Settings Strategy

Application Settings are setting that are set for the whole application, across all the load balanced web servers.

Host Settings are specific to the current host – ie, the load balanced web server the application is on.

At first glance, one would think that there are not many of these kinds of settings – but that's because you're not thinking about the Solution, only the Application. Boxes set up for DR have switches to use auxiliary network settings, etc.

Ah…too many times to count I've been involved in the production of a LOB/ application for an enterprise, where the notion of User specific settings (ie, User Preferences stored in a User Profile) have been cut. Arbitrarily. As if the end User/ was not important – only the paying Client/.

User settings is easy enough to configure (ok, it is harder than using AppSettings, but still…) that to make the program never remember their last preferred sort column, etc. – adding thousands of repetitive clicks to their years work – is a travesty.

Once you put in the UserSettings, you will be surprised to find how many places you'll find a use for it.

• Settings – whether App/Host/User – should not be serialized in the Db as Globs. The speed increase given by hitting the database for one record only,is – IMHO - outweighed by the complexity of not being able to when Caching would have been more appropriate) cannot compensate for a system that cannot be search/replaced easily with new settings later (binary globs can't be regex replaced, xml is slow enough to defeat the purpose of globs, etc.
• Think Modules. Think Vendors. Even if the app is for a Customer/ and not a Client/, think as if you'll be asked to add future modules to the app. In a commercial app, think as if there will be 3rd parties interested in writting plugins. In other words, ensure your apps are compartimentalizeable by Vendor/Plugin. In an enterprise space, that would come off as “MyClient/Core/MyVarA” , and later if they call you back, “MyClient/Phase2/MyVarA”…
• Think security between vendors. Windows' Registry Hive makes security people fall over with laughter in the way that it allows any vendor with access to the registry to read another Vendors settings. This should never be the case. Each vendor, each module should have access to only it's own mini hive of settings. What about shared settings between vendors? The hierarchical root should be where the common settings are placed, so that all the mini hives can travel upwards to common settings, not sideways to sibling settings.
  • See: User Preferences

    ### All 3 ###

In conclusion, every application should have the following services available:

• IApplicationSettingsService
• IHostSettinsService
• IUserPreferencesService