Whidbey Provider Design Pattern pitfalls

Note: this entry has moved.

A couple weeks ago Rob Howard (from the ASP.NET team) announced the "disclosure" of the Provider Design Pattern they are using in Whidbey ASP.NET (v2).

I've got a couple complaints with this implementation:

• Naming: Brad Adams (the guy behind design guidelines), is explicitly discouraging the practice of adding a "Base" prefix/suffix to abstract classes targeted to be the root of a class hierarchy. Yet, the pattern explained by Rob defines ProviderBase, MembershipProviderBase and so on. Not good. If these guidelines aren't followed by MS, you can't expect independant developers to do so, right?
  
• Collection typing: as defined, each functionality (i.e. Membership, RoleManager, etc.) defines a Providers property of type ProviderCollection, defined as follows: public class ProviderCollection : IEnumerable { // Methods // public void Add(ProviderBase provider); public void Clear(); public void Remove(string name); public void SetReadOnly(string name); // Properties // public ProviderBase this(string name) { get; set; } public int Count { get; set; } } Therefore, I need to cast whenever I need to access a particular provider. Now that Whidbey has generics, it seems appropriate to define the collection as: public class ProviderCollection<T> where T:ProviderBase : IEnumerable { // Methods // public void Add(T provider); public void Clear(); public void Remove(string name); public void SetReadOnly(string name); // Properties // public T this(string name) { get; set; } public int Count { get; set; } }

  Membership, therefore, would only need to define its Providers property as follows:

  public ProviderCollection<MembershipProviderBase> Provider { get; set; }
  
• Configuration:  As defined, the ProviderBase class contains an Initialize method with the following signature: public abstract void Initialize(string name, NameValueCollection config); Well, can anybody tell me why the config is not an XmlNode or an XPathNavigator at least? Given the configuration is already in XML form, why resort to converting it to a NameValueCollection?!
  Complex providers may need far more configuration that can't  be expressed with attributes in the element. This is a serious issue that may limit the usefulness of the pattern.

While the first two are a matter of taste in the end, the last one should be fixed promptly. I didn't hear any voice complaining, however. Am I the only one envisioning complex providers with the need to configure themselves with hierarchical XML information? It's all too common everywhere!
You want a a concrete example? Here it goes:

What if I develop a provider that implements automatic DB schema installation and migration? My super provider could allow the full DB schema to be specified in the configuration itself:

The provider can detect the presence of the schema and create it automatically if necessary. I could even go as far as saying that it could even define through configuration the way to migrate a schema if it's incompatible, or whatever.

Another one: maybe my provider uses a webservice. I may need to pass complex information to the provider, such as credentials, proxy information, SOAP message skeletons, or whatever. None of this is possible with a NameValueCollection.