Using multiple config files in a Provider Model scenario

We are using a Provider Model for a Payment gateways and I am hoping to figure out a way to do the following;

Each provider should have it's own configuration file. This will contain only the configuration applicable to that provider.

The consumer would have a configur开发者_如何学Pythonation file that stores only the entries that are required, such as Unity.The consumer would then load the providers via Unity.

We could potentially have a number of Providers and encapsulating the configuration of each means that can be pre-packaged and the only requirement on the consumer would be an alias to the Type and this could then be 'slotted in'.

As far as I can see, there is no way to have multiple configuration files and the provider's configuration is currently being ignored. However, I am hoping that perhaps a workable solution has been found by someone.

Thanks in advance

You can have as many configuration files as you like! Although you can only have one root config file per application, you can externalize most sections of this file into external separate files.

However, in this case, I'd be inclined to use XML files containing a serialized configuration object for each Provider.

Create a factory method to deserialize the config, build the configuration class and create each concrete Provider.

In your application config, just store the information required by the factory, such as the location of the XML configuration file for each provider.

Incidentally (& pedantically) - there is no such thing as a Provider Pattern. The Provider Model is typically implemented by combining Strategy and Factory patterns.

If you want these configuration files to be automatically consumed by the Configuration API in .NET, then to have multiple files you need to reference external configuration files from the central one loaded in the AppDomain on start up:

http://weblogs.asp.net/pwilson/archive/2003/04/09/5261.aspx

The Configuration API only goes looking for one file - this is likely why others are being ignored.

Alternatively, create your own configuration wrapper around the file and access it through this.

Again alternatively, there is nothing wrong with having one file contain all the relevant configuration sections.