Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB

10.1. Why Have Providers?

Traditionally, when a software vendor creates a programming framework or a software platform, a good deal of the framework logic is baked into the actual binaries. If extensibility is required, then a product like an operating system incorporates a device driver model that allows third parties to extend it. For something like the .NET Framework, extensibility is usually accomplished by deriving from certain base classes and implementing the expected functionality.

The device driver model and the derivation model are two ends of the extensibility spectrum. With device drivers, higher-level functionality such as a word processor is insulated from the specifics of how abstract commands are actually carried out. Clearly, modern-day word processors are oblivious to the technical details of how any specific graphics card displays pixels or how any vendor's printer renders fonts.

Writing software that derives from base classes defined in a framework or software development kit (SDK) usually implies another piece of code that knows about the custom classes you're writing. For example, if you implement a custom collection class, somewhere else you have code that references the assembly containing your custom collection class and that code also contains explicit references to the custom collection class.

What happens though if you want to have the best of both worlds? How do you get the separation of functionality afforded by the device driver model, while still ...