The Provider Pattern Is Not Just For ASP.NET
I have to admit that I have drank deep from the cool-aid pitcher that is the Provider Pattern. I love it for so many different reasons but there is a major misconception that is bandied about on the interwebs that I think should be clarified.
The Provider Pattern is not just for ASP.NET websites.
In my job I have to write a lot of software that runs as a background process which makes me pretty much a Windows Services guru.
I like to write windows services because when I'm assigned one of these projects I can be guaranteed to be sifting through 100% code, rather than 10% code and 90% presentation and aesthetics. I'm a programmer and even though usability fascinates me, any chance I get to completely forget about the needs of a user, I rub my hands together with glee.
The Problem
One of our large clients (call them "Client A") has a webservice that accepts money transfer transactions (think Western Union, kind of). The problem is Client A's customers aren't very technically savvy. Yes, they have programmers, but in general these programmers are only so in name and have a lot of trouble consuming our client's webservice.
You are a programmer and so your first reaction to this is to say "tough" to those who can't understand a webservice. The problem is that Client A sees themselves not only as a service provider but as a technology facilitator. They want to make it as easy for their clients to connect to them as possible. A few of their clients cannot work with webservices due to platform-specific technical challenges or they simply do not understand webservices.
But they all understand the delimited file.
Client A would love to accept delimited files, but all of his customers want to send him different file formats for delimited files and with different, very specific, rules governing files names, times of day to send files, etc. Plus, most methods of file transfer are insecure, etc.
The Provider Patterned Solution
Client A decided they wanted a windows service that was installable by any customer that had trouble interfacing with their webservice. They would be willing to pay for my company to develop custom code for each of their customers, but they wanted to keep costs low.
I created a windows service that had a provider patterned file handler that could be traded out with any other handler. This meant that for each customer Client A requested we write a handler for, all I had to do was implement a new provider. All Client A had to do was package the installer for the service with the .NET Assembly containing the customer's custom provider and voila!
The code for interfacing with the webservice is never touched and it is easy to maintain the code for the separate customers. If there is ever a change made to the webservice, I simply need to redistribute a new service installer, with no need to include the customer's provider - they already have it.
So, as you can see, the provider pattern isn't just for ASP.NET websites. It was made famous for configuring some of the new modules provided in ASP.NET 2.0, but it has uses beyond ASP.NET.
Trackbacks
Comments
No Comments
