Configuration best practices.

Topics: General discussion, Policy Injection Application Block
May 1, 2007 at 6:28 PM
May not be the best title, but right now I can't come up with anything better. I'm mainly concerned about how I'm going to interact with the PIAB, but I suppose this could apply to any of the application blocks and configuration.

It is my intention to use the PIAB as the basis for our new security model in a re-architecture of an existing product. A huge part of our product is customizations, both done by in house consultants, external consultants and our clients. So, I need to be able to dynamically build a configuration source for an object based on individual systems or even databases settings. They may define new policies than what we ship with, we may add some in future service packs, they may add totally new modules to what we ship and want to secure them. Basically, no one system will ever be configured the same.

I have been going down a path of building a DictonaryConfigurationSource from reading from a database (with the intent to cache a built-up configuration source to reuse) and using the FOR XML options and then de-serializing the result. However my current structures are not very flexible for collection type attributes in MatchingRules or Handlers. We will have several objects(in the hundreds) that could need a configuration associated with them. I was going to make the Assembly Name part of the table structures and filter on that, and if a Policy was "active" or not. I'm sure there will also be some Policies that we don't allow the user to see and are always active.

I've looked briefly at the SQLConfigurationSource QuickStart, and I'm not sure that will meet my needs, as I'm going to need to build a rather robust interface for building these policies (Sorry, the Enterprise Library Configuration tool isn't going to cut it). It looks like each section is just stored as XML in the database. While I could add some other filtering type columns to that, I don't know that having the XML chunks is the easiest way to deal with this, or for presenting it in a more robust Policy generator type application. I will more than likely have thousands of Policies for any one system(across several assemblies), so I don't think building one giant configuration file will be practical.

Basically, I'm not sure which direction to take this. I know I'll have to have something stored in a database, whether that is XML fragments, or fully normalized tables, I'm not sure yet. Is there anything out there that does anything similar? Any particular direction I should be looking at as a "best practice"?
May 22, 2007 at 3:12 PM
I am also very interested in the same problem (or preferrably a solution)

I my scenario, I need to provide the business users the ability to modify rules themselves. One simple example would be that we open up in a new market, and the validation now has to allow, say, "Germany" as a valid country for a reseller. I would certainly not want to give my business users the entire configuration file!

A nice way to store such settings in a database where I can make a nice UI on top would be really nice.

Morten