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?