none
Should I use ProviderBase for this, and if so how? RRS feed

  • Question

  • Hi,

     

    I have a very clear idea of what I want to achieve, but only a very vague feeling that I ought to be using the .NET provider model (possibly the ProviderBase or SettingsProvider, and related classes) to achieve my goal.

     

    The problem is, I'm not certain I should be using the .NET provider model , as I don't fully understand what it should be used for. And, if it is a good idea for me to use it, I don't know exactly which of those classes I should utilise and how.

     

    Here's what I want to achieve:

     

    I have an interface that defines a number of methods for working with .NET data classes. Here are a few examples of its members:

     

    • IDataParameter GetParameter<T>(string name, T value, ParameterDirection direction);
    • IDataReader ExecuteReader(string commandName IDataParameter[] parameters);
    • bool ExecuteNonQuery(string commandName IDataParameter[] parameters);

    Then I am going to build a number of classes that implement this interface and are geared towards a particular data store. I might call them "DataProviders", but that's just a name and doesn't yet link them to the .NET provider model. I'm thinking of creating things like "SqlDataProvider" (that would implement the interface to return SqlDataParameters and SqlDataReaders etc.) Or an "OracleDataProvider" or "AccessDataProvider" to do the same thing with their respective backing stores.

     

    Then, I want to be able to store the type name of the provider to use in an XML configuration file, say app.config or web.config. Areas of my application or web site would have configuration sections that allowed them to specify which of these implementations to use, and what connection string/credentials the concrete implementation should use.

     

    Just as a side note, I do not intend to use this model for each and every class in my code, as the "Class Factory" model might suggest I ought. (I'm using interfaces and careful planning to make my code maintainable and I feel a full blown class factory approach would be unneccessary and difficult to debug). I just intend to use it for aspects of my code (such as this database scenario) that I know will need to be easily decoupled and recoupled for different applications or different parts of applications.

     

    So I was wondering if anyone could advise whether or not there are base classes in the .NET framework that can provide a starting point to do this, and how you would go about solving my problem by extending those classes?

     

    I don't fully understand it, but I wondered if the SettingsProvider, ProviderBase and/or ApplicationSettingsBase are related to this kind of functionality, or if I should look elsewhere.

     

    Any guidance would be very much appreciated.

     

    Thanks.

     

    Ben

    Wednesday, April 23, 2008 1:18 PM

Answers

  • If you look at System.Data.Common, you'll see a class called DbProviderFactory. It is an abstract base class, and each concrete provider factory inherits it. For example, there's a SqlClientFactory and OleDbFactory. These factories allow you to build provider-specific database objects such as connections and commands in a fairly unified manner without having to know which provider you're specifically talking to.

     

    There's also a factory to build the provider factories - in the same namespace, the DbProviderFactories class. Each concrete provider factory is identified by an "invariant name", so for example, you can use the following code to get the SqlClientFactory:

    DbProviderFactory = DbProviderFactories.GetFactory("System.Data.SqlClient");

     

    Thursday, April 24, 2008 6:03 PM

All replies

  • What version of .NET are you using? The ADO.NET classes (connections, command, parameters, datareaders, etc.) all use a provider model from version 2.0 on. In other words, there is already an IDataReader interface with concrete implementations for SqlClient, Oracle, OleDb, etc. and each concrete implementation has it's own provider, with a common provider factory.

     

    Wednesday, April 23, 2008 9:14 PM
  • Hi, Rob,

     

    Thanks for taking the time to reply.

     

    I'm using .NET 3.5, so I'm interested in your suggestion.

     

    I know about the IDataReader, IDataParameter interfaces and their concrete implementations for each provider. I'm not proposing that I re-create those .NET classes and interfaces, of course! Those interfaces are merely the return types of members constituting the interface and classes I'm proposing.

     

    I'm afraid I don't understand the very last part of your last sentence, which I think is going to be crucial to answering my question. "each concrete implementation has it's own provider, with a common provider factory". Could you tell me more about these "providers" and the "common provider factory", please? What are their class names and in what namespace can I find them, so that I can research them? Maybe they could be exactly what I'm looking for, maybe not.

     

    Many thanks for your interest and help

     

    Ben

    Thursday, April 24, 2008 10:58 AM
  • If you look at System.Data.Common, you'll see a class called DbProviderFactory. It is an abstract base class, and each concrete provider factory inherits it. For example, there's a SqlClientFactory and OleDbFactory. These factories allow you to build provider-specific database objects such as connections and commands in a fairly unified manner without having to know which provider you're specifically talking to.

     

    There's also a factory to build the provider factories - in the same namespace, the DbProviderFactories class. Each concrete provider factory is identified by an "invariant name", so for example, you can use the following code to get the SqlClientFactory:

    DbProviderFactory = DbProviderFactories.GetFactory("System.Data.SqlClient");

     

    Thursday, April 24, 2008 6:03 PM
  • Thank you, Rob.

     

    These classes seem to be what I'm looking for.

    I'll learn how to use them and post again if I have any problems.

     

    I appreciate your input.

    Monday, April 28, 2008 8:55 AM