Assume that you have a hierarchy of organizational units:
- Company
-- Branches
--- Departments
---- Teams
Lets say I have some settings (for simplicity assume that they have the same properties) for each level of hierarchy:
- Max nr of documents
- Min something else
- Can do X
- Can do Y
- many other properties
So, the sub-units can reuse as default the parents settings, or they have only one or two of these settings modified. Same for their sub-units.
What would be the proper pattern to follow – both as code structures, as well as db storage to support that, with the idea that each unit’s settings can be modified independently, and sub-unit’s settings override the default of the parent.
We were thinking about key/value pairs, and then lookup for each one going up the hierarchy until we find the right setting, but this can become ugly pretty fast.
Another option we were considering is that each unit has it’s own record of the settings, and update accordingly when parent’s settings changed.
I’d appreciate any suggestion of well known approaches/patterns in that regard.
The design I follow is to only set what’s overridden. So I would have a full set of default settings. Then at the company level I would override only those that are different. At the branch level I would only override those that are different than the company or default. And so on. In that way the settings build up from the base. Changing a lower level setting will “bubble up”. This also keeps your data set as small as possible.
At the application level, assuming the set is relatively small, I would load all of the defaults, then the relevant company’s overrides, then the relevant department’s overrides, etc. into one data set. You can then look up any setting from that one list.
I’m not sure there’s an actual, well known OO design pattern for this, but it’s quite similar to how ACL (permissions) are applied in most file systems, so you could read up on that.
Matt S’s suggestion is pretty much correct. I would recommend storing the settings as full sets, with an option for “unspecified”. TortoiseHg, the popular Mercurial front-end for Windows, does it as follows:
Notice the options to leave things “unspecified”, which would leave the setting to whatever was set at a higher level. Also, notice that there’s 3 levels here:
Factory defaults -> “User’s global settings” -> “Repository Settings”
Each getting progressively more specific. As long as you can resolve your hierarchy into a simple linear format like this, the task is quite simple. Start with the least specific set (which should have actual values for everything), and then simply apply the next level of settings to it. If anything is “Unspecified”, leave it alone. When you run out of levels of settings, you’ve successfully resolved the settings for the user.
It might be a good idea to keep track of which setting level applied each setting, if only for debugging / information purposes.