Brian Mishler on .Net

As an Independent Software Vendor (ISV), I make my living writing a software program and (hopefully) selling it many times. For the most part, the application meets the customer’s requirements right “out of the box” and if there is a gap, the customer is usually able to work around it.  Every now and then, a potential customer will dangle the carrot out there, that if certain features are added then they’ll buy a lot of copies. Or, they would buy it if it could be integrated with their existing XYZ-system. 

Now I’m not talking about the practice of accepting customer suggestions for a systematic improvement of a maturing product. I’m talking about adding appendages where they just don’t belong. Over the years, I’ve occasionally succumbed to these pressures and in some cases, the products were better off for it. Other times, the extra features were like anchors around our feet as now had customer-specific business rules in our mainstream product.

The Provider Model

I’m sure the Provider Model has been around for a while but I first heard the term “Provider” back when Microsoft was introducing its “Universal Data Access” strategy (I seem to recall this was all part of the transition to MDAC.)  For the next few years, of course, we all used the “ODBC Provider” or the “SQL Server Provider” in our database applications and (at least I) did not think much more of it.

In general, the provider model is a design pattern that allows, through configuration, an alternate provider of application functionality to be substituted with requiring modification to the primary application.

(There’s probably a better text-book definition for this but my definition suits me just fine)

A few years back, I read a couple of articles on MSDN about “Providers” and proceeded to build my own for one of our products, the PocketForms Web Service. I was intrigued about the idea of letting customers easily override the default implementation of any of my web methods and figured this might provide a nice “catch all” for the occasional special-requirements customer.  Back then, there was no base provider class in the .Net Framework but several good examples were available for guidance.

I found that most of the work was actually in setting up various configuration classes that would be used to manage optional user settings. The application, itself, required some fairly straight-forward design changes, mainly in creating a new “MustInherit” base class that defined the interfaces that my existing class already implemented.  All-in-all, it took just a couple of days to retrofit my existing application with this new design pattern.

Fantastic Return on Investment

I must say that the investment in learning about and implementing the Provider Model has been one of the best decisions I have ever made professionally. As it turns out, most of our customers take advantage of this in one way or another. Some have custom authentication requirements, some want to do special handling with posted data and others just want to log certain activities.

Last year, we released our Sharepoint Bridge which is a “shrink wrapped” provider to make our product work with Sharepoint Portal Server and Windows Sharepoint Services and have attracted a lot of attention from organizations that wanted an easy way to push mobile data into their existing Sharepoint-based intranet. This extra capability can be customized and improved on its own product cycle without ever affecting the functionality of the primary product. And, as we upgrade our web service with additional features, our custom providers continue to work.

Now easier than ever

With the release of the .Net Framework 2.0, Microsoft included a base provider class in the framework itself.  We were able to dump all of our plumbing code and simply inherit our base classes from the new System.Configuration.Provider.ProviderBase class.  The various configuration (ConfigurationSection, ProviderCollection, etc.) classes have also been simplified, so we cleaned up our existing configuration code as well.

There are plenty of articles on MSDN and elsewhere on using the provider model, so it would be redundant for me to go through all that here. In a future post, I plan provide a real working example in case anyone wants a nice starter project.

Not just for Asp.Net

With the release of Visual Studio 2005, Microsoft showed off the new Asp.Net Membership System in just about every presentation they gave. Everyone was impressed with the instant login and user creation controls and when Microsoft was asked the question “what if we want to change the implementation”, they were able to point to the provider-based implementation of their Membership System. Since there is such a high adoption rate of the Asp.Net Membership System, many folks associate the term “provider” with the Role, Membership and Profile providers in Asp.Net. Many programmers will go on to assume that this means the “AspNetSqlRoleProvider”, “AspNetSqlMembershipProvider” and “AspNetProfileProvider” and lose sight of the fact that these are just the default (if not the most common) implementations of the base provider classes. 

More and more ISV’s are recognizing that this model is not only useful for supporting unplanned circumstances but will also become more in demand with the increased adoption rate of Microsoft’s development platforms.  The investment is minimal and the potential rewards are significant. As I evaluate new applications, I have gotten into the habit of reading the configuration files and lately have seen an increased number of “shrink wrap” programs that have some form of provider-based implementation. One good example is Telligent’s Community Server that appears to have largely been built on base provider classes. I have not seen much documentation on this but I would assume that Telligent built it this way so that organizations could swap out some of the implementation.

The provider model works well for Asp.Net (web) applications since the appropriate provider is loaded once and based on the settings in Web.Config. It also works well for WinForms applications, although a change in the application’s configuration file does not automatically cause a running application to restart and reload a different provider.

From one ISV to another…

So, if you are an ISV building solutions on the Microsoft .Net platform, you owe it to yourself to consider a provider-based implementation of your application. You’ll find you are able to satisfy many unexpected requirements and not have to saddle your application with extra features that will need to be optionally disabled in future releases.  Another big benefit is the additional revenue stream you open up with new add-on products like your “Oracle Provider” or “SAP Provider”.

I love this subject and, while I have had a lot of success in actually using it, keep finding there is more to learn. Your comments are welcome.

Brian Mishler