Encapsulating ADO.NET
A couple of real world examples of providers that are useful in almost every application are that of an encapsulated data access layer and a configuration management component. Data access layers use providers to perform dependency injection, allowing for multiple different implementations of a set of data access interfaces, with each implementation exposing functionality to communicate with different data sources. This is a fairly common form of encapsulation that many developers are already familiar with implementing, but there are still many areas in which the correct provider and package design can return many architectural, maintenance, and extensibility benefits. Providers should be completely decoupled from the data access layer proper, as should the interfaces that define the actual data adapters and classes with which a consuming layer will interact.
Configuration Management Provider
One of the purposes of building a custom configuration management provider is to allow for settings to be stored in different locations. By abstracting the location away from configuration querying, the business choices about where to store configuration information can change without causing high maintenance expense within the application itself. A dependency injection (dynamic class loading) methodology is used to instantiate a configuration management provider class at runtime, allowing the provider to be switch based upon a configuration setting in the .NET configuration filesfile. While that may make it sound as though the abstraction has been broken, remember that only the configuration management implementation is being stored in the .NET configuration file, in only one place. This is a nice single layer abstraction of the configuration strategy and removes reliance upon the .NET config files, locations, and structures. The argument for this is to allow for a business to choose to, for example, switch to storing configuration settings in the registry based upon the result of a security audit that declared file-system based configuration files as unsecure. Because the configuration manager that is used to manage the configured provider list is also configured within the .NET configuration files, even that manager can be changed out cheaply and easily at a later date in the project if business decisions require such a change. It is important to understand that this is a good balance and trade off from over-engineering. Simple abstraction is not an over-engineered solution. Authoring a second configuration manager "just in case it's needed" would be an over-engineered solution. Providing the hooks for extensibility is simply good architecture and this kind of planning will save many projects from show-stopper changes that classically would cause engineering nightmares. The extensibility and flexibility of a well abstracted architecture allows engineers to adapt to technology and business changes by planning for the possibility of such changes ahead of time.
OnDeserializeUnrecognizedAttribute
One great idea I was able to glean from a section of today's talk on custom configuration section handlers was that of the OnDeserializeUnrecognizedAttribute method. This is a virtual method that can be overridden from within a custom configuration section handler that will be invoked when an unrecognized attribute is encountered in a configuration element. This allows for a custom configuration section to use proprietary attributes without requiring those attributes to be added to the recognized schema proper. An example of this is with the configuration for a set of connection string storage locations. Nearly all of the locations, whether file, database, smart card, or registry, have the same list of basic attributes. However, the registry might have additional proprietary attributes for the hive and keypath. It is not ideal to have to add these attributes to the schema that will contain only null values for every other source. In this case, it is ideal to let the OnDeserializeUnrecognizedAttribute method handle those two attributes and write a small amount of custom code in that method to retrieve the values from the configuration element.