Sun has always felt a need to educate its developers. Sometimes this has led to Pearl Harbour scale disasters like J2EE, but it has also produced an extremely technically literate community. On the other hand, sometimes you wish Microsoft didn’t even try. I’ve pretty much come to the conclusion, for instance, that the Microsoft Enterprise Library is the Wrong Thing. Every so often, we come across stuff which falls under the heading of “mistakes you need a PhD to make”, as Francis Fukuyama describes his advocacy of the invasion of Iraq. The provider pattern is top of my list here. If you’re not familiar with this, it’s a Microsoft-specific form of pluggable singleton. It’s a singleton by virtue the “default provider” mechanism. It’s extremely over-complex and, in my experience, just plain doesn’t deliver any benefits that plain old using constructors wouldn’t achieve better.
By combining the singleton pattern with a pluggable architecture, they hoped to draw the poison from the pattern. Anyone who’s used it will know this isn’t the case.
- Sometimes the pluggability just plain fails: try find the parent node from a plugged sub-sitemap.
- Sometimes its insistence on using concrete types for everything makes your code nigh-on impossible to implement (especially if some third party made the same decision…)
- Since it’s a singleton and hence can have shared state, you need to be writing thread-safe code. Not a trivial task for a neophyte developer who just wanted a bit of pluggability.
- Since it doesn’t have a coherent dependency injection model, you often end up using the Microsoft configuration model to get anything done. (You do get a set of string name/value pairs, but any complex dependencies will fall down badly.)
- Worst, when you finally discover that you actually wanted two of something, you get reminded that the provider pattern remains a special case of the singleton pattern.
It is in many ways really impressive, but that’s what makes it especially pernicious: it picks up a lot of developers who are trying to improve and leads them down blind alleys. You can spend a lot of time supporting a provider pattern. When you start to figure out that it’s not really paying back the investment, you’re going to feel that much of this patterns stuff is just nonsense. Tell me you don’t know a developer like that…
Ironically, you know one really obvious user of the provider pattern? Subtext, the blogging engine that powers, um, this site…
Colour Coding 
While I’d agree completely with the first statement, but I’m going to contradict the second. The problem is, the Provider pattern is the equivalent of a corkscrew/hammer: it’s meant to put in nails, but to do it, you’re expected to turn it. And it doesn’t work very well. So, the question is, short of using the factory code to do the factory thing (e.g. using the default user provider to provide a logon page using the default logon control) what use is it? I’d never recommend you implemented a new provider pattern for any significant piece of functionality. Instead I’d recommend you went away, read Clean Code, and learned how to design flexible systems.Let’s try argument from authority: Phil Haack had serious problems in his user community when he used a non default user provider. More generally, since he now runs the ASP.NET MVC project, and has never implemented a single provider pattern within it, I suspect that he regrets ever using it by now. Screwturn also found that it’s hard to get right.There are tools for spiking code, and there are tools for building maintainable systems. The problem with the provider pattern is, it claims to be for producing maintainable code, but the ROI just isn’t there. And it’s way too painful to use for a quick spike.Finally, this all ignores the fact that there’s an extremely good alternative pattern that addresses all of the concerns of the provider pattern but is easier to get up and running, requires less code to be written and is flexible in the long term. It’s called an IoC Container. To go back to Phil, he’s recently added direct support for IoC Containers into ASP.NET MVC. I note he hasn’t done the same thing for provider patterns.
LikeLike