we have recently decided to transfer all our app configs to the database.
right now we consider all these configs to be both readable and writeable.
but we want to future proof it so that if a certain client decides to make a certain category of configs to be only readable we could manage it.
at the moment a single business object reads all the configs from the database and stores them.
the following is a simple schema representing our table.
CREATE TABLE GlobalSettings ( SectionName VARCHAR(50), SettingName VARCHAR(50), SettingValue VARCHAR(1000), SettingType TINYINT );
my question is that how should we design our class so that we can achieve this?
The client can arbitrarily change some configuration values to read only? Or would this be a one time change and the category would be read only forever? it sounds like you should create a permission for each category and the have auth rules to ensure the logged on user can edit those settings. of course you'd need a more privileged user permission that can grant or deny these permissions, probably a system administrator role.
Or maybe you should replicate the "storage" part of appsettings - "Application" and "User".
We have done pretty much the same in some applications and provide values from a webservice.
We decided to male a "global" - read-only - settings service and a editable service for "user settings".
Where is the "client" entity in the settings part? Would it be application or is client another type of entity?
We have Application as part of the settings table to provide settings to multiple applications.
There is also an accompanying ASP.NET MVC application for editing values - and there we have the option of specifying users/roles for each application that are allowed to edit the read-only settings.
(we also cache the output from the webservice so that it is more efficient - and do not want to do frequent changes in production).
One more thing you might want to add is valid_from/valid_to datetime fields if you want to have some settings only become effective from a given date/release.
Copyright (c) Marimer LLC