The Provider Model: Usage Guidelines

Ryan Whitaker wants you all to stop the Provider Model madness that apparently is about to explode. Kinda funny. A preventative strike against Provider Terror throughout the world. Heh.

I do agree with him on the specific point he makes. You should not use the Provider Model for unnecessary extensibility. What extensibility would be unnecessary? Well, as Ryan states, the off-chance that you'll swicth from using one third-party component to another. Remember, you CAN have too much of a good thing.

Here is a guide to determining when you SHOULD implement the Provider Model for an application subsystem:

  • If the subsystem is part of a workflow that is anticipated to change often enough that the application will have to be frequently redeployed.
  • If the app specs require the subsystem to be able to process information through multiple channels simultaneously. For example, you need to send an order out to multiple vendors, three of which use distinctly separate web services, and one uses e-mail.
  • If the app specs require public third-party extensibility, meaning that end-users need to be able to write their own providers.

So when shouldn't you use the Provider Model? That's an easy one:

  • Data Access Layers. DO NOT use the Provider Model to write data access logic. ADO.NET 2.0 has built-in capabilities for that. I will post code demonstrating this at a later date. UPDATE: There are some exceptions to this rule, which I will discuss later next week.
  • Utility apps. If you're the only one that is ever going to use the program, there is no sense in investing the time necessary to construct a well-designed Provider Model architecture.
  • Component-swapping. Back to what Ryan said before.... just don't do it.
  • Because everyone else is doing it. Come on. Be an architect. Think your design out, and only use it if it makes sense to.

More Provider Model-related news coming shortly... stay tuned.

10 Comments

  • "Data Access Layers. DO NOT use the Provider Model to write data access logic. ADO.NET 2.0 has built-in capabilities for that. "

    Oh? It has object creation facilities, which are great, but these don't do the native SQL actions for you, like SqlServer specific identity column handling vs. Oracle specific sequence column handling, paging on sqlserver vs. on firebird, vs. on db2 vs. on oracle etc.



    The provider model in a DAL allows you also to produce per-database SQL tweaking.

  • A Provider Model implementation on a DAL would be a waste of time in most situations. MOST times, people really don't have to think about switching databases, and shouldn't spend their time architecting internal corporate applications as such. Especially in Fortune 500 companies, they are contractually bound to support a given database for a given period of time. That being said, of course there are exceptions to the rule.



    And Frans, you can write your code in such a way to be able to handle those DbProvider-specific functions based on the current provider, after you've already instantiated the object, without having to build a ProviderModel-based Static API for data access... which involves MUCH more than has been discussed up to this point.

  • I'll have code posted to demonstrate ADO.NET Provider-agnostic DALs soon. I had a basic one set up for my AZDNUG presentation, and I wanted to give it a bit more robustness.

  • I have to disagree about the DAL not being a candidate for the provider model. We have the business case that our code is SQL based now, but 6 months down the line we might have to have our entities flow through a web service or even some sort of mixed mode where the entities are torn apart and half saved to a db and half go to a db. By doing a provider model we can support this easily.

  • Lots of companies that SALE software have to support multiple databases in order to compete. This is common in healthcare and financial industries, and I'm sure many others too.

  • Great. Read what I said. "There are some exceptions." And again, ADO.NET 2.0 has facilities that encompass 95% of the logic to do that stuff with, without having to build your own thread-safe, static API and configuration handlers for it. There are many cases where doing it with the new ADO.NET 2.0 would be much quicker and more effective.

  • The Provider Model, like any hot "new" thing that comes along, will get overused. I was just posting my thoughts since I've already seen it unnecessarily used in places. Not so much a pre-emptive terror strike, although it'd be easy to cull that from my post.



    Like in anything, be careful when you use such concrete declarations such as "just don't do it" when talking about component-swapping. There are times and places for almost everything, but only do those things where they're needed.

  • What will happen in the future is up for speculation, however that the provider model has benefits, especially in the DAL area is something you can't degrade with pointing to some feature in ADO.NET 2.0. The thing is: creating an IDbCommand object of a given ado.net provider flavor is one thing, what you are going to do with it is another. And the latter is the most important one, not the creation of some object with a factory.



    Anyone who has done development for multiple databases knows that a data-generic dal is only possible if you can abstract away the SQL you have to execute and all the mumbo jumbo around it. Good example: a resultset returning stored procedure with parameters. On oracle this works with cursors. You have to bind a dataset to the parameter(s) representing the cursor(s). This is totally different from the sqlserver approach and requires different code. I.o.w.: you can jump up and down all you want that you can create IDbCommand and IDataAdapter implementing instances using a mechanism, the code USING these instances is hard to get database generic.



    "And again, ADO.NET 2.0 has facilities that encompass 95% of the logic to do that stuff with, without having to build your own thread-safe, static API and configuration handlers for it."

    To do what, Robert? :) Sure, and no-one will deny that, the ado.net 2.0 model will solve some problems with the various factories for the provider specific objects like OracleCommand. However that's just a small thing compared to what has to happen next. The example I gave with the oracle stored procedure is one which shows that Data-Access is not something that can be abstracted away with some object factory. You NEED database specific providers which will do these things for you so the code can work with multiple databases. And if you think accessing multiple databases is something only 4 people on the whole planet will want/do, you are mistaken :)

  • Frans,



    I'd say you haven't spent much time working with ADO.NET 2.0 yet. I say that because, if you HAD, you would know that you don't work with Interfaces anymore. ADO.NET 2.0 uses an abstract base class approach. And there is nothing say you can't test for the resulting object that is created, and work with it from there.



    But then Frans, my question is this: have you even worked with the Provider Model yet? I mean, have you built your own Provider managers? Have you built your own .NET 2.0-based static, thread-safe Provider APIs? Do you have a product out now that does? From what I know at this point, that answer is "no". But then again, I've been wrong before. More often than I'd like.



    All I have to say is this... if you HAVEN'T yet, why don't you wait until I post the code before commenting further? You never know, I MIGHT, God forbid, know a little bit about what I'm talking about.

  • Someone posted comments about the PM being just thye factory pattern, and I wanted to respond. You won't see the post thought because the guy thought it was ok to whip out the obscenities.



    It's NOT the factory pattern. Had you watched my webcast on the Provider Model last week, you would have found out that it is actually the combination of four different design patterns to create a new design pattern.



    If you want to talk about it not being new, your better bet would have been to say that Javas's had it forever in the "class loader".



    Next time, don't swear in my blog.

Comments have been disabled for this content.