Tim Barcz

Ditching the provider model design pattern

After much thought, I've ditched the provider model design pattern in a program I'm working on.  I thought the provider model was going to be perfect for this situation.  It still might be.  I made the decision to drop it thought based the time it takes to implement versus simply coding it as a one-off.

Why I chose the provider model in the first place:

I'm writing a "module" that imports content from a third party into our content management system application.  There are certain things that need to be done to a file once I have it in my hands before the import.  Many of the things than happen though after I have my hands on the content, is very standard.  I thought to myself, that the provider model would be perfect since we could theoretically be sucking in content from many different sources.  The fact that *where* the information came from was irrelevant to the general page import.  I wanted to be able to say, "Whereever I'm getting my content (provider) retrieve me a collection of pages that I need to import".  The idea being whether I was using and XML file, flat file, or access database shouldn't matter to the importer.

Why I felt this decision was a bad one:

I was able to get the content into the form I wanted easy enough but then I came to a point where I need to do some translating on a file.  Updating html image links for example.  Each translation would be different based on what the feed gave me.  In order to code with the provider model I would've had to abstract an interface call ITransformation or something like that and have a collection of them registered with my concrete provider such that my importer could cycle through each ITransformation object calling a singular method, Transform().

As it turned out I was doing so much work on each concrete provider compared to the amount of work was being done by the importer.  In other words, the importer was getting the content to import from the provider and then doing very little to it, albeit important, but very little.

What I did instead:

I decided to scrap the provider model then to write a straight forward import process that deals in this case with one feed source from start to finish.  It was much clearer due to the removal of the abstraction.  Probably saved me some time as well (disregarding the time I spent implementing the provider model in the first place).

Ultimately we will only really be using probably five different feed sources.  An argument could be made that that would be enough for the abstraction, but at this point I would disagree.  I eventually felt like I was building such an elaborate system all the while wondering why I didn't just go back and write it as a one-off.  In the end that's just what I did.

What it a good choice?  What would you have done?  Do people actually read this far?