On Utility of Provider Model

I’m putting in my best effort to understand how your would retrofit the Provider Model into an existing web application. Scott Guthrie posted a nifty how-to on putting together a couple of server controls, the membership system and custom profile properties to streamline user registration and account management. I dare to say that most of us (if not all) have written this by hand at some point in time, so it’s good to see this streamlined.

The new providers alleviate the burden of maintaining membership information in various storage media: SQL Express, SQL Server and Active Directory. You can write your own custom providers to talk to DB2, Oracle, data files of arbitrary format, or “Microsoft SQL Server databases with custom schemas”.

Therein lies the irony: how many databases out there do not fit into the category of Microsoft SQL Server databases with custom schemas? Just about all of them. Which brings me to my point.

How many applications manage only user profiles and their membership roles? Does it make a useful application? Hardly. With providers, you have to bank on a database that is created for you and whose schema and data you do not control. It’s out of your hands. I think it’s fair to say that a lot of applications have users at their core, with everything else bound to their profiles: purchase orders, billing and shipping information, download history, email preferences, and so forth. You end up with user profiles in one database managed by the Role, Membership and Profile providers, which the rest of data is stored in a separate database.

How do we tie the two islands of data? From the technology standpoint, this is no rocket surgery. From the development and operations standpoint, it makes no sense—there’s no value in doing it. Since every existing database has a schema foreign to the Provider Model, it would require a custom provider to talk to it, and I can’t see a good reason to write one: the business value of it is zero. Welcome to the real world.

Another gripe I have with it is that we will be writing more code, not less. Look at a custom membership provider and see if you get any excited about writing one and whether you can justify to your management why you need this 2.0 wonder instead of the existing working code.

Looking at all providers, I feel they are way too overcrowded. I can bet money 20% of methods would be used at all with 80% throwing NotSupportedException. If that’s the case, why not provide reasonable, default implementation to the 80% of methods and hide them behind another layer of inheritance? Give me something I can use; don’t throw all that stuff at me and expect me to dig myself out.

What’s your strategy for adopting (or retrofitting) providers?

>What’s your strategy for adopting (or retrofitting) providers?

throwing a lot of NotImplementedExceptions. :-)

I completely understand what you mean. While doing some recent development I considered using ASP.Net 2.0. After doing some research and found lots of information on the Member/Role/Profile Provider model and thought it was an interesting approach and that I would like to adopt it since they are always touted as being highly customizable.

After implementing the Role and Membership providers I realized that this customizability did not save as much time as I was hoping... in fact it took more time because I wanted to have a better understanding of the classes I was inheriting from. It stripped away a layer of abstraction that would have sped things up, but that's the battle we all face when programming in .Net I suppose. All I can say is that the Reflector program was extremely useful in helping me program my custom providers.

I just can't agree too much with your comment. At first, it looks like it's perfect. But real world applications won't just use the default providers from Microsoft, and we have to end-up writing our own.

Indeed, writing a provider is very scary. For this one and the role provider, Iwhen trying to do so.
was scared at how many methods need to be implemented
This is proven by the fact that you can hardly find any other provider on the Web by now. I was looking for one that would store the profile in an XML file - can't find it.

I looked at the sql database and sprocs created. It was silly looks like it was designed by a three year old.